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