Provide pkg-config files

[IvanUkhov]

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

[xianyi]

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.

[rafalcode]

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}

[IvanUkhov]

@martin-frbg, I think it should be kept open until openblas.pc is provided; please see #1084.

[martin-frbg]

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.

[martin-frbg]

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.

[IvanUkhov]

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.

[martin-frbg]

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 ?

[IvanUkhov]

@martin-frbg, I think the concern about CMake that you brought up is an important one as well.