[petsc-dev] Sean is going to love this

[Satish Balay]

I think packaging systems have more info about the (pre-requisite)
packages - so they are in a better position to specify the exact link
list ( as suggested via CPPFLAGS/LDFLAGS) - so they should avoid using
--with-hdf5-dir=${prefix} type options as much as possible.

So PETSc should support all external package detection via
CPPFLAGS/LDFLAGS with a corresponding --enable-package option.

[If I remember correctly - petsc configure parses LDFLAGS and
reformulates the user specified value (for eg: "/foo/libbar.a" is
changed to "-L/foo -l bar" by petsc configure - which might not be
what was intended) - so we had to add in LIBS option for equivalent
functionality - perhaps this should be rectified]

Satish

On Tue, 23 Dec 2014, Barry Smith wrote:

> 
>  Pretty much
> 
> > On Dec 23, 2014, at 6:45 PM, Sean Farley <sean.michael.farley at gmail.com> wrote:
> > 
> > 
> > Barry Smith writes:
> > 
> >>> On Dec 23, 2014, at 6:11 PM, Sean Farley <sean.michael.farley at gmail.com> wrote:
> >>> 
> >>> 
> >>> Barry Smith writes:
> >>> 
> >>>>  Sean,
> >>>> 
> >>>>   Say I am writing a PETSc package (for any generic packaging system) that will use the MPICH compilers package and the BLAS/LAPACK package (and say, the hdf5 package). How do I indicate to PETSc's configure the information for MPICH, BLAS/LAPACK, and hdf5 so they will be correct for users when they link and run their applications? That is, I don't want to randomly list some hdf5 on the system but is it enough to just list the exact location of the hdf5 I know the package manager will install hdf5 to?
> >>> 
> >>> That is a hard problem. Jed and others will chime in on this problem,
> >>> but this is why some packages have a binary / script that outputs its
> >>> compiler / linker flags. For example, netcdf has nc-config:
> >>> 
> >>> $ nc-config --has-hdf5
> >>> yes
> >>> 
> >>> $ nc-config --libs
> >>> -L/opt/local/lib -lnetcdf
> >>> 
> >>> There is also pkg-config:
> >>> 
> >>> $ pkg-config --libs libpng
> >>> -L/opt/local/lib -lpng16
> >>> 
> >>> Ideally, package managers should provide this information. Currently,
> >>> they do not. For PETSc, this would mean something akin to 'petscmpiexec'
> >>> and / or supplying this information to pkg-config (this actually should
> >>> be fairly easy).
> >>> 
> >>> An end-user would then use pkg-config or a PETSc-provided script for
> >>> compiling and linking,
> >>> 
> >>> $ pkg-config --libs petsc
> >>> -L/opt/local/lib -lnetcdf -lpetsc -L/opt/local/lib/mpich-mp -lmpi -lpmpi
> >> 
> >>  Yeah in theory we do this.
> >> 
> >>  But this actually doesn't answer my question; I'm also asking about the situation when the package system (like brew) is compiling the package on the users machine.  Say I need the -I info for hdf5 to pass to PETSc's configure. If the user has selected a nonstandard location for installs with brew(not /usr/local) how do I know what directory to pass with the -I ? Somehow the package system has to provide the information for me to use in calling configure.
> > 
> > Ah, sorry, then I misunderstood. This is definitely dependent on the
> > package manager system. In MacPorts, this is just listing the libraries
> > directory:
> > 
> > configure.args-append --with-hdf5-dir=${prefix}
> > 
> > The requirement (of most?) package managers to have a locked-down prefix
> > (e.g. /opt/local) is that installing something outside of the package
> > would break the above code.
> > 
> > In some package managers (MacPorts is an example), CPPFLAGS are set to
> > ${prefix}/include and LDFLAGS are set to ${prefix}/lib. To prevent
> > over-linking and help deter incorrect linking, there is a trace mode
> > that sandboxes the whole process so that only dependencies are
> > explicitly allowed.
> > 
> > Is that what you were asking?
> 
>