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 <[email protected]> wrote:

Barry Smith writes:

...

...

On Dec 23, 2014, at 6:11 PM, Sean Farley <[email protected]> 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?