more comments about new build system

[Stephan Kramer]

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

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

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