new build system

[Stephan Kramer]

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