Just because you can do it doesn’t mean you should do it. Barry
On Oct 29, 2013, at 2:07 PM, Barry Smith <[email protected]> wrote: > > It is not worthy any additional logic in the already messing configure > process to save a few downloads. > > Barry > > > On Oct 29, 2013, at 1:59 PM, Satish Balay <[email protected]> wrote: > >> On Tue, 29 Oct 2013, Jed Brown wrote: >> >>> Barry Smith <[email protected]> writes: >>>> Or simpler just have the —with-clean nuke external packages; makes >>>> life easy. By "store the tarballs in a common place” and SHA1 crap >>>> you are making the system more complicated to understand and >>>> maintain. >>> >>> People will complain when they have to download the same tarball many >>> times. But I don't especially care as long as the builds are done >>> inside $PETSC_ARCH instead of in a common place. (This is also useful >>> when building multiple configurations of PETSc in parallel.) >> >> There is also the issue with git repos to deal with. [presumably the >> above logic would be slightly different than the tarballs] >> >> We [Jed and I ] also discussed having git repos and corresponding >> tarballs match - and caching tarballs locally for unreliable external >> sites. And then using SHA as a way of versioning to eliminate most >> cases where with-clean would be needed. >> >> Just a note: all these issues are primarily with git users - not >> petsc-release/tarball users. >> >> Satish >
