[petsc-dev] PETSc-3.4 PR open at https://github.com/Homebrew/homebrew-science/pull/343

[Jed Brown]

Barry Smith <bsmith at mcs.anl.gov> writes:

> 1)  So what directories should we be generating in the prefix location and

$prefix/include and $prefix/lib at a minimum.  If we need to install
binaries, they go in $prefix/bin/petsc*.  Other non-library files go in
$prefix/share/petsc/*.  We should not use $prefix/conf because it is
non-standard.  (And even if we did, we cannot steal non-namespaced paths
like $prefix/conf/rules because PETSc should be installable to
prefix=/usr/local without creating a mess.)

> 2) exactly what files should we be copying over (currently I think we
> just copy entire directories worth of material which results in
> garbage being moved over)

Yeah, that's the problem now.  We need to copy headers, Fortran modules,
libraries, pkg-config file.  The matlab/octave stuff should install to
$prefix/share/octave/packages/petsc/* and something similar for Matlab
(I'm not familiar with their conventions).

> 1)    prefix/bin
>        prefix/share
>        prefix/include    prefix/include/mpiuni (when needed)  prefix/include/petsc-private      prefix/include/finclude  and various other subdirectories for f90?
>        prefix/lib   prefix/lib/modules  (Jed says prefix/lib/petsc/modules)   I see a lib/modules/3.4.2 why does this have a version number and nothing else?

Judging from NERSC's configuration it looks like it should be $prefix/modulefiles/petsc/3.4.2.

>        prefix/conf ?

This is non-standard.  Yes, changing it will change all makefiles, but
we have to namespace that stuff anyway so let's decide how to do it
right.

>     What is the rule for putting a "petsc" subdirectory in the middle?
>     My guess is that it is being put in whenever a "nonstandard"
>     subdirectory is put in. What defines a "nonstandard" subdirectory?
>     Isn't mpiuni a nonstandard subdirectory? 

It is conventional to use $prefix/include/$PKG/*.h to keep headers
contained.  However, I'm leaning toward saying that if MPIUNI is being
installed, mpi.h should go to the top level ($prefix/mpi.h) so that it
works like normal.

>     What about finclude? 

Everything in finclude is itself namespaced (or should be).  I'd rather
put it in $prefix/include/petsc/fortran/, but finclude is not totally
violating our namespace.

>     What about conf? 

Nobody else uses conf so we shouldn't either.  It looks like the CMake
convention (at least that used by KDE) is for $PKG to install
/usr/lib/cmake/$PKG/${PKG}.cmake.

>     What is the standard for where module files are put, not allowed
>     directly in the lib directory? But not in a "standard" modules
>     subdirectory? Some people advocate modules in prefix/finclude.
>     Since include is supposed to be reserved for C includes should our
>     finclude directory not be under the include directory?

Are you talking about Fortran *.mod files?  I'm not sure.  MPICH,
NetCDF, and HDF5 install $prefix/include/$PKG.mod while Open MPI
installs $prefix/lib/openmpi/mpi.mod.

>   We should try to be as "standard" compliant as reasonable.  Should
>   we be adjusting the non-prefix installs as well?

Yeah, the user should not need to know whether they are using a prefix
build or not.  I'm in favor of adding a simple $prefix/bin/petsc-config
script.  If pkg-config is available, it could even be implemented in
terms of calls to pkg-config with paths set appropriately.  This would
allow people to avoid including PETSc's makefile (which brings unknown
variables into scope) and instead write

CFLAGS := $(shell $(PETSC_DIR)/$(PETSC_ARCH)/bin/petsc-config --cflags)

pkg-config is better in principle because being a single tool, it can
sort any dependencies (only really relevant when using static libs) and
can report cases of conflicting flags.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mcs.anl.gov/pipermail/petsc-dev/attachments/20131012/762bce1e/attachment.sig>