[petsc-dev] broken builds

[Barry Smith]

  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