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

[Barry Smith]

  It seems you are willing to drop the /petsc/ portion of some things (like finclude) if all the files are name spaced inside but I like total consistency. Why not 

  prefix/include/petsc  subdirectory of finclude and private (won't need the petsc- part anymore)?
  prefix/lib/petsc          subdirectory of modules?
  prefix/share/petsc    subdirectories of data  and conf?
  prefix/bin/petsc  

    then we can organize everything inside the PETSc subdirectories the way we like.  But, of course, #include <petscvec.h> won't work even if prefix is /usr without a -I and -lpetsc won't work without a -L  But we don't generally talk about using PETSc that way anyways (since for portable makefiles for different installs of PETSc on different systems one shouldn't assume -lpetsc works).  Makes removing all petsc stuff easy also.
   Barry


On Oct 12, 2013, at 5:33 PM, Jed Brown <jedbrown at mcs.anl.gov> wrote:

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