[petsc-dev] Github/TravisCI: caching petsc fails - is there a workaround ?

[Franck Houssen]

rm -f arch*/lib/petsc/conf/pkg.* works great ! Thanks Satish.

Franck

----- Mail original -----
> De: "Satish Balay" <balay at mcs.anl.gov>
> À: "petsc-dev" <petsc-dev at mcs.anl.gov>
> Cc: "Franck Houssen" <franck.houssen at inria.fr>
> Envoyé: Mardi 23 Janvier 2018 18:52:47
> Objet: Re: [petsc-dev] Github/TravisCI: caching petsc fails - is there a workaround ?
> 
> BTW: - if you are doing some caching - you might be able to cache
> prebuilt externalpackage includes/libraries - and avoid
> --download-package option.
> 

For now, I try to do thing the most simple/natural way: --download-metis/mumps is OK so I kept that, --download-openmpi/boost triggered problems so I compile them.
I prefer to start simple and "complexify" step by step when needed (autodetection KO, reach time limit, ...).

> i.e use --with-package-include --with-package-lib options [or
> --with-package-dir option - if autodetection works]
> 
> Satish
> 
> 
> On Tue, 23 Jan 2018, Satish Balay wrote:
> 
> > Not sure I understand the issue here.
> > 
> > But If you are looking for a way to force PETSc configure to always rebuild
> > externalpackages - you can:
> > 
> > rm -f PETSC_ARCH/lib/conf/pkg.*
> > 
> > Satish
> > 
> > 
> > On Tue, 23 Jan 2018, Franck Houssen wrote:
> > 
> > > Hello,
> > > 
> > > On Github/TravisCI, caching petsc fails: is there a possible workaround ?
> > > Let's emphasize this: as I suspect this could have deep impacts, I am not
> > > asking for a fix. I just would like to know if there's a (known ?) trick
> > > to workaround this.
> > > 
> > > Go here https://github.com/fghoussen/geneo4PETSc on branch "caching"
> > > (note that caching is OK for openmpi and boost).
> > > Commit 611ee54 creates the cache (to be re-used by future commits).
> > > Commit 0cffa91 try to reuse the cache but fails with " Downloaded metis
> > > could not be used. " line 2615 in the travis log (see also line 3255).
> > > Commits cfa36ff and bf33c3b try to remove external packages
> > > (partially/totally) but unfortunately this does not help.
> > > And... I am left with no more idea / solution.
> > > 
> > > Is there some kind of trick like "removing CMakeCache.txt when using
> > > cmake" to "screw" the configure and let him think he has to restart
> > > everything even if "everything" (compilation objects) are already there
> > > ? (save compilation time)
> > > 
> > > I would totally understand you don't want to invest time on this. But if
> > > there is a know solution, this will be helpful.
> > > 
> > > Franck
> > > 
> > > Note: if you are not familiar with TravisCI, here is how its works. You
> > > have a 49 minutes time slot to go. If you go linux, you get a trusty (=
> > > ubuntu-2014-LTS...) what is more than 30 minutes long to upgrade
> > > (upgrade OS + compile openmpi boost petsc slepc which are outdated even
> > > after upgrade). If you go osx, both starting and running a job are VERY
> > > slow (5 to 10 h to start, slow build and no time to do what you would
> > > have done with linux - got no idea why ?!...). So all this to say that
> > > the time you have left for testing is significantly reduced. At this
> > > point caching is really critical...
> > > 
> > 
> > 
> 
>