On Wed, 2007-06-13 at 21:39 -0500, Barry Smith wrote: > Sounds like it should be > > /usr/include/petsc/2.3.3/opt/*.h > /usr/bin/petsc/2.3.3/opt/petscmpiexec > /usr/lib/petsc/2.3.3/opt/libpetsc.a > /conf/petscrules > > > Is this correct? > > Barry
Sounds pretty reasonable. Apart from the /usr/bin, you're really not allowed to make your own subdir in /usr/bin. Contrary to what the name suggests /usr/lib is for libraries and executables (as long as they don't need to be in the standard path of users or shell scripts). How you want arrange things further inside /usr/lib/petsc is pretty much up to you. Sorry to be so pedantic about standards, but these things become really important when you are no longer only dealing with rather experienced developpers installing PETSc on his own system to link with their own model. If you want your library to be used by other, more general and widespread, software, the developpers of that software need to rely on a standard configure/make/install that can simply pick up an installed petsc. They have to deal with their own users, many of whom may not be all that much interested in the ins and outs of PETSc. In that respect a related question: is it really necessary to have incompatible changes between sub-sub-versions of PETSc? Most software only makes backwards-incompatible changes when bumping their mayor version number. I must say that I was not really amused when I found out our software would not build with PETSc 2.3.3, because of various small namechanges, such as KSPSetMonitor -> KSPMonitorSet. Although I can see the logic behind most of these, it would have been nice if for instance both names were kept, or to save up such small changes until Petsc 3.0.0. You have to realise that distributions are not going to distribute 15 different versions of PETSc, which would be necessary if you have other packages that rely on a specific version of PETSc. One last thing about the use of /etc/. I would be really wary about using it. The primary use of it is for configuration files that are to be changed by users. This means that on most distributions, if you make changes in one those files, and a new petsc comes along, it will not be so straightforward to upgrade these files (i.e. the distribution will not let you change files that were touched by users). Cheers Stephan
