more comments about new build system

[Satish Balay]

On Wed, 13 Jun 2007, Stephan Kramer wrote:

> Hi Barry, Lisandro,
> 
> I'm afraid you're working with too many constraints here. If the new
> PETSC_ARCH-less installation (a move I strongly encourage BTW, I myself
> am packaging local Debian packages for internal use in our computational
> group) is to be of any use to package maintainers it has to adhere to
> the File Hierarchy Standard (FHS), http://www.pathname.com/fhs/.
> 
> This would mean using (roughly what Lisandro already suggested)
> 
> prefix/bin
> prefix/lib
> prefix/include
> 
> and possibly prefix/lib/petsc/ and prefix/share/petsc/. prefix/conf and
> prefix/etc are definitely out of the question, and so is /etc (this is
> for configuration files that change the run time of programs, so only a
> petscrc like file would be suitable there).
> 
> The only way that I see you could combine this with a PETSC_ARCH
> approach is if you leave PETSC_ARCH at the end of lib and put the libs
> in:
> 
> prefix/lib/petsc/PETSC_ARCH

Actually we are not planning of supporting PETSC_ARCH in the prefix
mode [only the non-prefix mode - where the libraries are residing
inside the PETSc source tree - where FSF etc don't matter]

> A standard distribution would probably have a standard optimised build
> and one with debugging. They probably still want the optimised libs in
> /usr/lib for the other packages to find, but they can make sym-links if
> they want to. I know this conflicts completely with the current
> PETSC_ARCH+PETSC_DIR  installation, hence my comment about conflicting 
> constraints: you can't combine this with a FHS compliant installation.
> I would suggest getting rid of the build-independent files altogether 
> (so each build has its own set of include files and 'bmake' files). This 
> solves the problem of include files having to find another directory, there 
> will be only one for each build:
> 
> prefix/include/petsc/PETSC_ARCH

I think to support multiple PETSc installs in /usr [via .deb or .rpm],
the packagers have to use --prefix=/usr/lib/petsc-debug
--prefix=/usr/lib/petsc-opt [or more appropriate names per the
packagins standards they use], and then create links from /usr/include
& /usr/lib to the default versions.

Satish

> 
> The makefiles can go into prefix/share/petsc/PETSC_ARCH, with the include 
> and lib directories explicitly filled in during configuration. Duplication of 
> the make and include files can't really be an argument in terms of size, but 
> maybe I'm overlooking something here. This way you have far more flexibility, 
> for instance you could at the same time also offer an option for a PETSC_ARCH
> less installation that simply installs in prefix/lib and 
> prefix/include.
> 
> As I said I really appreciate a change in the installation, as the current 
> practice is a bit of a pain. When writing a configuration script for software
>  that depends on PETSc, you want it to find out the petsc dir for itself, and 
> not requiring the user to set PETSC_DIR and PETSC_ARCH.
> 
> Cheers
> Stephan Kramer
> 
> 
> 
> 
> 
> 
> 
> On Tue, 2007-06-12 at 19:44 -0500, Barry Smith wrote:
> > 
> > On Tue, 12 Jun 2007, Lisandro Dalcin wrote:
> > 
> > > On 6/12/07, Barry Smith <bsmith at mcs.anl.gov> wrote:
> > > >    I understand. But we cannot have
> > > > $PETSC_DIR/conf and $PETSC_DIR/$PETSC_ARCH/lib/petsc
> > > > both directories have similar contents but very different
> > > > types of names.
> > > 
> > > Sorry, my brain is not working well today. I forgot something.
> > > Currently, in the 'build' directory, we have to use use the following:
> > > 
> > > PETSC_DIR/conf  --> move to --> $PETSC_DIR/lib/petsc
> > > 
> > > Would this work? I am (again) missing something?
> > 
> >   The problem I see with this is that how they are included in
> > users makefiles changes. In one case you 
> > have 
> > include PETSC_DIR/conf/base
> > in the other case (installed case)
> > include PETSC_DIR/$PETSC_ARCH/lib/petsc/base
> > one of the goals of this change is to continue to 
> > user identical user makefiles in either case.
> > 
> >    Barry
> > 
> > > 
> > > 
> > > 
> > > 
> > 
> 
>