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

[Barry Smith]

  This whole prefix/include and prefix/lib seems rather silly and archaic; who uses it but the gnu/linux people ?  For example on MacOS the PETSc install location is /Library/Frameworks/PETSc.framework,  on Windows they must have some convention but it sure as hell doesn't use include and lib. 

   Why does the linux world (which is tiny) cling to this archaic model?

   Since the #include <petsc/petscvec.h> can handle the includes, it all comes down to the single -llibpetsc issue of working without requiring a -L flag. We could put the library in prefix/lib/petsc and then make a link back up to the prefix/lib directory.

   We could also put put everything in prefix/petsc and then scatter the needed links in for the standard locations.

   Has anyone in the gnu/linux world came out with viable replacements for the /include  /lib  mess they have now that allows all the parts of a library package to go together rather than being spewed in several directories?

   Barry



On Oct 12, 2013, at 6:18 PM, Barry Smith <bsmith at mcs.anl.gov> wrote:

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