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