[WIP] Add pkg-config output

[victorapm]

This PR adds pkg-config info to the installation directory of HYPRE (hypre-install-path/lib/pkgconfig/HYPRE.pc)

This is a metadata file that application codes can use to gather details about HYPRE, including information on how to compile and link against it.

Example:

$ export PKG_CONFIG_PATH=hypre-install-path/lib/pkgconfig
$ $(CC) `pkg-config --cflags --libs HYPRE` -o myapp myapp.c

This fulfills xSDK - R5, particularly this line

[rfalgout]

Hi @victorapm . Thanks for putting this together. The general approach we use in our linux build system is for the 'all:' target to both build the library and also temporarily install it in the 'hypre' subdirectory. Then, the 'install:' target simply copies the installation from there to another location. So, I think you should put the 'HYPRE.pc' pkg-config stuff in the 'all:' target instead.

A question. The output I get from running 'pkg-config --cflags --libs HYPRE' is (on my Mac)

-I/Users/falgout2/Documents/hypre/src/hypre/include -L/Users/falgout2/Documents/hypre/src/hypre/lib -Wl,-rpath,/Users/falgout2/Documents/hypre/src/hypre/lib -lHYPRE -lm

Is this what the xSDK requires? It doesn't show the MPI dependencies, for example (because we use an 'mpicc' script). Just wondering. Thanks again!

[victorapm]

Thanks for the review, Rob! I'll make the fix you suggested.

I see your point regarding the MPI dependency. It makes sense to me to include this information in the *.pc file, but there isn't a mechanism in pkg-config to include the compiler used to build a given library. Not sure how to proceed here, @balay can you advise?

[balay]

xsdk "recommended" policy is very generic - it suggests providing useful info - perhaps via pkg-config - but doesn't list or mandate the details on what combination works and what does not work.

For this - I can refer to what we currently have in petsc. [its usage is minimal - so might still have issues.]

Attaching one pkg config file generated by PETSc. [with MPI, Hypre, BlasLapack]

petsc.pc.txt

And the suggested usage is at:

https://gitlab.com/petsc/petsc/-/blob/main/share/petsc/Makefile.user

[victorapm]

Thanks for providing this info, @balay! Very helpful!

I wasn't aware of the --variable method for retrieving compiler info. I guess we can do that for hypre as well.

[balay]

Perhaps this is more relevant to the xsdk text:

$ pkg-config --libs --static petsc
-L/home/balay/tmp/petsc-install/lib -lpetsc -L/home/balay/tmp/petsc-install/lib -L/home/balay/soft/mpich-4.0.1/lib -L/usr/lib/gcc/x86_64-redhat-linux/13 -lHYPRE -llapack -lblas -lm -lX11 -lmpifort -lmpi -lgfortran -lm -lgfortran -lm -lgcc_s -lquadmath -lstdc++ -lquadmath

[victorapm]

Thank you! Quick question: should we include rpaths in the --libs output?

[balay]

Hm I don't see that in current petsc pkg-config

$ pkg-config --libs petsc
-L/home/balay/tmp/petsc-install/lib -lpetsc

@jedbrown added this to petsc - and understand these requirements/usage-patterns better.

BTW: I think one use case could be for using pkg-config to implement FindHypre() for CMake - [and this might be more robust than alternative modes of manually detecting hypre?]

[victorapm]

Thanks! Indeed, the cmake use case is compelling!

[jedbrown]

RPATH is a choice for the person linking, not a choice that libxyz.so can make. Since there are multiple syntaxes for rpath flags, petsc.pc does provide a key ldflag_rpath with the flag (see pkg-config --variable=ldflag_rpath petsc. A caller from CMake would never use that because CMake has its own way to specify using RPATH.

[victorapm]

Thanks @jedbrown! I'll remove the rpaths from Libs and provide a ldflag_rpath as PETSc does