BTW: - if you are doing some caching - you might be able to cache prebuilt externalpackage includes/libraries - and avoid --download-package option.
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... > > > >
