Provide pkg-config files
Closed this issue · 13 comments
I am curious if there is any particular reason for not providing an adequate openblas.pc file when installing OpenBLAS. It would be great if OpenBLAS was properly discoverable via pkg-config so that the packages that dependent on OpenBLAS need no worry about compiling their own versions of OpenBLAS. Netlibs, for instance, does this diligently. Thank you.
Regards,
Ivan
Thank you for the suggestion. The reason is that I don't know how to write pkg-config file. :)
I add this to feature request list.
This worked for me
cat /usr/local/OpenBLAS/0.2.18/lib/pkgconfig/openblas.pc
prefix=/usr/local/Modules/modulefiles/tools/OpenBLAS/0.2.18
exec_prefix=/usr/local/Modules/modulefiles/tools/OpenBLAS/0.2.18
libdir=/usr/local/Modules/modulefiles/tools/OpenBLAS/0.2.18/lib
includedir=/usr/local/Modules/modulefiles/tools/OpenBLAS/0.2.18/include
Name: OpenBLAS
Description: Xianyi's OpenBLAS libraries
Version: 0.2.18
Libs: -L${libdir} -lopenblas -lpthread -lgfortran
Cflags: -I${includedir}
@martin-frbg, I think it should be kept open until openblas.pc is provided; please see #1084.
Closing was automatic as the number was mentioned in the commit message, sorry. Your objection regarding the naming in case of parallel installs of netlib or atlas does have some merit though keeping it the same as netlib seemed natural at first. (Maybe one needs to check what atlas or similar do, if they provide pkg-config files at all - perhaps duplicate names are not a problem as long as they live in separate paths ?)
I suspect the file generation code may also need to be copied to CMakeLists.txt for cmake builds before this can be closed.
Confused - depending on where one looks it seems there is no consensus on whether there should be just one openblas.pc (and atlas.pc etc), competing blas.pc,lapack.pc files each in their own directory or blas-implementation.pc (blas-atlas.pc, blas-openblas.pc etc) and corresponding lapack-implementation.pc.
It’s of course up to you. I personally vote for openblas.pc. The name of the project is OpenBLAS, and the name of the library being installed in openblas. Then openblas.pc says exactly what it has to say. It’s simple, direct, and follows the established conventions (you don’t typically see libraries adding any prefixes or suffices to their pkg-config files). If there’s a disagreement about those other auxiliary pkg-config files, they could be dropped for now, and only the main pkg-config, openblas.pc, could be installed.
From my limited understanding, pc files do not claim to provide a specific "well-known" capability, but just a mechanism for reporting all the flags and paths necessary to use that particular library or project when one already knows that one wants to do this(?). If that is the case, the layout and naming chosen by netlib may simply reflect its history as separate BLAS and LAPACK codebases and "we" would not gain anything from copying it for OpenBLAS (worst case would be linking the same library twice, once as "blas" and once as "lapack" if the system is naive enough to not recognize that).
@isuruf would you be fine with a modification of your contribution that renames the "blas.pc" to "openblas.pc" and either drops all the copying to other names or keeps it commented out as a potential starting point for distributions that prefer blas-openblas.pc or similar naming scheme ?
@martin-frbg, I think the concern about CMake that you brought up is an important one as well.
Certainly, and should be easy to "steal" from the netlib snippet you linked to originally.
@isuruf would you be fine with a modification of your contribution that renames the "blas.pc" to "openblas.pc" and either drops all the copying to other names or keeps it commented out as a potential starting point for distributions that prefer blas-openblas.pc or similar naming scheme
Sure. I'm fine either way.
Could explain a bit more what problems you foresee from having blas.pc and openblas.pc, @martin-frbg? While one could get the same flags passed to the compiler twice, I'm not entirely clear on how this presents a problem. Is there something I'm missing?
My concern was about having a separate blas.pc and lapack.pc both suggesting the same libopenblas.so (or perhaps more relevant, libopenblas.a). Even if it is no problem, I am not sure what could be gained from such a setup - at least under the assumption that pkg-config cannot answer general questions like "what provides BLAS functionality on this system" but only "what options do I need to specify when I want to use OpenBLAS".
@jakirkham if there is some advantage to having multiple blas.pc,lapack.pc etc I would certainly like to know - I tried to outline my observations and conclusions on this topic in the earlier comments but they are just that.
When I dropped the other files from Isuruf's original PR I thought about leaving the relevant lines in Makefile.install as comments, but then decided against it as I figured that it would make no difference from a distribution maintainer's standpoint if a patch was required to remove a hash character from the start of a line, or to add that same line to the file.