[petsc-dev] broken builds

[Satish Balay]

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
> 
>