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.far...@gmail.com> > > wrote: > > > > > > Barry Smith writes: > > > >>> On Dec 23, 2014, at 6:11 PM, Sean Farley <sean.michael.far...@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? > >