But we've been promoting a lot of users to use petsc-dev as superior to using the release tarball - so can't really provide this difference of behavior for developers vs users.
Perhaps its simpler to just provide 'hg clean' for 'rm -rf PETSC_ARCH' which takes care of reconfigure.py aswell. for eg: ./configure --cleanbuild or ./$PETSC_ARCH/conf/reconfigure_$PETSC_ARCH.py --cleanbuild Satish On Tue, 30 Aug 2011, Barry Smith wrote: > > Jed has the confidence of youth, that he can add all these features without > creating a Frankenstein monster that swallows up all our time and energy. > > > --download-package has one purpose. Get the requested tarball, configure the > package, compile the package and move the results to the appropriate place. > These are all appropriate for a ONE TIME install of a package where that > same source code or compiled stuff is not intended to be used in the future > under different circumstances. > > To save people's (mostly PETSc developers) (waiting around) time we added > two very limited features > > 1) not get a new copy of the tarball from the website each time > 2) not recompile the libraries if no configure options have changed > > both of these additions are very fragile. Jed seems hell-bent on making these > two features less fragile by turning this code into a more feature rich > package system. I am not sure this is a good use of our resources perhaps the > better approach is to turn off limited features 1 and 2 in release tarballs > to prevent average joes from shooting themselves in the foot but allow > developers the faster reconfigure times. I don't see any business model > where it would make sense for us to try to turn the --download feature into a > fully robust package model. Just a big time sink and the only reward is the > developers don't need to worry about using rm once in a while. > > > Barry > > > > > > On Aug 30, 2011, at 3:34 PM, Matthew Knepley wrote: > > > On Tue, Aug 30, 2011 at 8:30 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote: > > On Tue, Aug 30, 2011 at 15:25, Matthew Knepley <knepley at gmail.com> wrote: > > How exactly would we keep track of that? Go and look to see what kind of > > crazy shit was generated by the 'make install' in SuperLU? > > > > Install it to a temporary directory and compute the manifest on that. > > > > http://aur.archlinux.org/packages/su/superlu/PKGBUILD > > > > Most packages support DESTDIR which makes it simpler. > > > > Which breaks things that bake in the install directory name. And some > > packages have a workaround > > and some don't, which is again a less than robust way to operate and I > > think will create more headaches > > than it solves. > > > > Matt > > > > -- > > What most experimenters take for granted before they begin their > > experiments is infinitely more interesting than any results to which their > > experiments lead. > > -- Norbert Wiener > >
