Installation of pkg-config / cmake files depend on libdune<module>

changed milestone to %DUNE 2.10.0

@simon.praetorius , @santiago.ospina Can you give some insights? You were the last to work on this part of the code.

The related commit is quiet old: cbdd8182 (>10y old) It was motivated by multiarch platforms. Maybe at that time the differenciation between lib and lib64 was not an issue? We have not touched this since then. But I had the same impression that it is complicated to find all the files when you have multiple different modules, some with and some without a proper library.

~~My suggestions would be to use always CMAKE_INSTALL_LIBDIR, but I'm not sure about the consequences. This should be checked.~~

On my understanding, these paths should be chosen when one has multiple binary formats. I don't think we have that. In either case, CMAKE_INSTALL_LIBDIR seems to do the correct thing. However, note that it will change the final destination in Debain to lib/<multiarch-tuple> when installed into /usr. Since CMake is has the monopoly on how to solve these paths for dune, I don't think this is a problem at all.

mentioned in merge request !1341 (merged)

closed

This is actually not about a package having multiple binary formats. It is about allowing distributions to install library packages in multiple binary formats. E.g. on Debian you can install libraries for other archictectures in addition to the host architecture.

So if you have installed libraries for multiple architectures then you would still always use the same dune-istl which is only installed once (and not multiple ones for no reason). That is why the package configuration file do not go to architecture dependant directories. Now you will at least need to install multiple Cmake configuration files for a package even if it has no library. So I do think that the old way was the right way.

We will probably need to revert this on Debian. This might turn out to be much more work there than the old version would have been here.

So I am wondering, whether !1341 (merged) does save anybody work. If not it would be nice to revert it as it does impose a maintenance burden for packagers. (Maybe this is a bit exaggerated as there are no library packages for Debian and hence we cannot install for multiple architectures without overwriting files. But maybe that changes sometime)

An alternative is to a have a possible to override this and use this override method e.g. for dune-istl. Or does it maybe have a library now?

In my understanding, dune-istl is not affected by this change because it produces no object library. Indeed, your argument supports this change because libraries like dune-common or dune-grid were installing their object libraries in the wrong place all this time thus creating an unnecessary maintenance cost to packagers.

In any case, if this creates unreasonable maintenance cost as you say, having a custom variable for this could be an option.

...

From: Markus Blatt (@markus.blatt) gitlab-reply@dune-project.org Sent: Wednesday, January 31, 2024 9:20:18 AM To: Ospina De Los Rios, Santiago Subject: Re: dune-common | Installation of pkg-config / cmake files depend on libdune (#361 (closed))

Markus Blatthttps://gitlab.dune-project.org/markus.blatt commented#361 (comment 133759):

So I am wondering, whether !1341 (merged)!1341 (merged) does save anybody work. If not it would be nice to revert it as it does impose a maintenance burden for packagers.

— Reply to this email directly or view it on GitLab#361 (comment 133759). You're receiving this email because of your account on gitlab.dune-project.orghttps://gitlab.dune-project.org. Unsubscribehttps://gitlab.dune-project.org/-/sent_notifications/REDACTED/unsubscribe from this thread · Manage all notificationshttps://gitlab.dune-project.org/-/profile/notifications · Helphttps://gitlab.dune-project.org/help

like dune-common or dune-grid were installing their object libraries in the wrong place all this time thus creating an unnecessary maintenance cost to packagers

Now I am surprised. Where will libdunecommon be installed now? I thought that this is still the same as before.

You made me really nervous, but luckily it seems like you are wrong. The change is only for modules without libraries.

Sorry, my bad, I didn't check what was actually happening in the actual installation process. I only read the CMake documentation. Investigating a bit more, apparently CMake does not apply the multi-arch prefix on Debian anyways because of some internal problem with updating the CMAKE_INSTALL_LIBDIR variable. So ends up being lib again.

Now I am surprised. Where will libdunecommon be installed now? I thought that this is still the same as before.

If they didn't revert that change, it would be in /usr/lib/<multiarch-tuple>.

[...]. The change is only for modules without libraries.

Ok, I see the problem. CMAKE_INSTALL_LIBDIR (and likewise should be DUNE_INSTALL_LIBDIR) is in theory for "object code libraries (lib or lib64)" like libdunecommon.[so|a] or libdunegrid.[so|a]. But now I see we are putting more stuff in there...

Ok wait. Before discussing further maybe let me go through the code this or next week and have a better overview where things are being installed and where they are supposed to be.

Markus, thanks for sharing your doubts! a) I stumbled across this issue while packaging dune-typetree 2.9.1 for openSuse. The same packaging code as for other dune modules lead to different installation locations. This should not happen, and it took me a while to figure out that the difference is triggered by the fact whether a module provides a library or not. Dune-localfunctions is affected as well. b) There is more than just Debian. In Suse the installation on i585 is /usr/lib/ and on x86 is /usr/lib64/. The latter did not work as intended.

If the current patch is not enough, we have to improve it. Should we use GNUInstallDirs, as mentioned in CMake's documentation?

We are using GNUInstallDirs, see files: dune-common/cmake/modules/DuneDoxygen.cmake dune-common/cmake/modules/DunePkgConfig.cmake dune-common/cmake/modules/DuneProject.cmake

The fact that there was a problem for dune-typetree and not for dune-istl is a bit smelly

Dune-istl is affected, too. My list of affected modules was not complete. I just wanted to point out that the wrong behavior can be seen from core modules.

reopened

ok, I have investigated a little bit:

There is a variable DUNE_INSTALL_NONOBJECTLIBDIR (default="lib") referring to "Installation directory for libraries that are not architecture dependent. Default is lib when not set explicitly"
If there is an exported library, all libraries are installed into CMAKE_INSTALL_LIBDIR (this is recommended by debian, See https://wiki.debian.org/Multiarch/Implementation, section "CMake".
If there is no exported library, the variable DUNE_INSTALL_LIBDIR is set to DUNE_INSTALL_NONOBJECTLIBDIR
DUNE_INSTALL_LIBDIR is used to define the install location for cmake files only. Thus, if a module has an exported library, the cmake files are put into the corresponding multi-arch lib directory, e.g. /usr/lib64/, otherwise in the DUNE_INSTALL_NONOBJECTLIBDIR
Additionally, the DUNE_INSTALL_NONOBJECTLIBDIR is used for the install location of the dune.module file.
libraries are always installed into the CMAKE_INSTALL_LIBDIR

Consequence:

Since libraries are always installed into CMAKE_INSTALL_LIBDIR, I would also always put the cmake files next to it
The only alternative that makes sense is to put cmake files of modules without a library into the share/ folder, instead of the lib/ folder.

This all boils down to the question where cmake searches for packages: In order

<prefix>/(lib/<arch>|lib*|share)/cmake/<name>*/
<prefix>/(lib/<arch>|lib*|share)/<name>*/
<prefix>/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/
<prefix>/<name>*/(lib/<arch>|lib*|share)/cmake/<name>*/
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/
<prefix>/<name>*/(lib/<arch>|lib*|share)/<name>*/(cmake|CMake)/

To summarize:

In case you have a module library and compile for multiple architectures e.g. i386 and amd64, you get multiple libraries and need separate cmake config files for each arch. This is correct.
In case your module does not create a library, the question of multi-arch does not apply and you should store the cmake files in a common directory, e.g. lib/ or share/. In my impressions lib/ is a bit surprising, because you do not create a library. share/ instead is for files shared by all architectures and thus the right place.

So, the current behavior is actually (nearly) correct. Just the choice lib/ for non-arch-dependent files might be questionable. I propose to change this to share/.

Putting everything into lib64/ (aka CMAKE_INSTALL_LIBDIR) is not ideal, but would probably work on single-arch systems as well. On multi-arch setups you might get identical files installed in multiple lib folders. Probably this would also not hurt.

I follow your arguments, I remain unhappy with the result. After installing the core modules on openSuse (probably similar with Fedora and Red Hat) we would end up with:

/usr/share/lib64/pkgconfig/dune-common.pc
/usr/share/lib64/pkgconfig/dune-geometry.pc
/usr/share/lib64/pkgconfig/dune-grid.pc
/usr/share/lib/pkgconfig/dune-istl.pc
/usr/share/lib/pkgconfig/dune-localfunctions.pc

Same happens with our CMake modules.

happy or unhappy is not a criterion here ;-) Let's look what other libraries do:

Eigen3: all cmake files are in /usr/share/eigen3/cmake/...
boost: only cmake files for library targets, located in /usr/lib/x86.../cmake/boost_xxx/...
PETSc: provides libraries, .pc file in /usr/lib/x86_64-linux-gnu/pkgconfig/PETSc.pc
Craig Scott recommends to use share/ for header-only libraries (https://discourse.cmake.org/t/what-should-the-destination-be-for-a-header-only-librarys-cmake-config-file/8473)

Other blogs put header-only libraries also in CMAKE_INSTALL_LIBDIR, e.g. https://rs-stuff.dev/2021/10/31/cmake-install/

Thanks for digging up other examples. I don't mind the place we decide to put the files. I want to have all the pc files ending up in the same folder or folders following the same logic for all modules - regardless of the module providing a library or not.
Imagine the worst case, dune-istl will provide a library in version 2.x+1 and the pc file from 2.x remains in a different library. A nightmare to debug!

mentioned in commit 7eea319e

closed with merge request !1341 (merged)

Installation of pkg-config / cmake files depend on libdune<module>

Designs

Child items ...

Activity