Any interest in better supporting library consumers who use CMake with find_package

[Ryanf55]

Use Case

I would like to use a tool such as LibUUID in a CMake project.

Similar to Kitware who need LibUUID in their code, the current approach would be to write my own find script.

util-linux has a ton of libraries, and I understand the maintenance burden of supporting another build system. On the other hand, some recommendations consider this as a bug that C++ libraries are missing basic CMake support.

Other approaches are rebuilding libuuid in another repository, but this neglects what the packaging maintainers of my system deem is appropriate.

The request

Is there any potential that util-linux could start to better support consumers who use CMake by distributing either find or config modules for libraries that include CMake targets that express their properties along with versioning information?

Preferred Usage

find_package(LibUUID 2.37 CONFIG REQUIRED)

add_executable(foo main.cpp)
target_link_libraries(foo PRIVATE LibUUID::UUID)

Options Proposed

• Use CMake's PkgConfig support and distribute FindX.cmake for each library (can add to libraries on-at-a-time)
• Code-generate the CMake scripts (automated but initial legwork to stand this up)
• Add CMake as a build system to util-linx (big ask)

[karelzak]

We already distribute pkg-config files. I do not see a problem with adding another file that will be useful for different use cases (CMake). The question is only how difficult it will be to generate and maintain it.

• is it possible to generate the file (config) from some template by sed(1) (autotool or meson)?
• can you provide an example for libuuid?
• where will it be installed (after "make install")?

(Note that I have no experience with CMake.)

[Ryanf55]

We already distribute pkg-config files. I do not see a problem with adding another file that will be useful for different use cases (CMake). The question is only how difficult it will be to generate and maintain it.

• is it possible to generate the file (config) from some template by sed(1) (autotool or meson)?
• can you provide an example for libuuid?
• where will it be installed (after "make install")?

(Note that I have no experience with CMake.)

Yes. I'll put together a native build example for CMake, and then another example that uses the PkgConfig export in two different branches for you. CMake itself generates most of the installation files when doing a native build. The more that existing tools can be relied on, the better.

Other things of interest I just found:

• If you build with meson, you can call cmake.configure_package_config_file which then requires only maintaining the myProject.cmake.in file. This does not support versioning from the looks of it though.

Most importantly, I'm glad you are open to improving usage in CMake; some other packages are hostile to CMake - this is a nice change in pace 👍 .

[Ryanf55]

Where are all the HAVE_FOO definitions set, such as HAVE_NANOSLEEP?

Here's a prototype for a native CMake build.
https://github.com/util-linux/util-linux/compare/master...Ryanf55:native-cmake?expand=1
Because I ran into build errors, I wasn't able to generate the installation files yet. Feel free to follow the instructions I added to try it out.

Based on the amount of conditional logic in the top level meson.build, I do not see this approach as feasible to convert the build system to CMake, at least without some serious time commitment.

I'll send over the alternative option when I get time.

[karelzak]

Well, I thought all we need is some template.in file to produce a simple config file to have the libs easy to access for CMake. I really don't want another build-system (like we have autotools and meson).

I thought about an alternative to pkg-config (libuuid/uuid.pc.in), or so.

[Ryanf55]

Craig Scott's book "Professional CMake" has chapter 35.9.2 on Config Files For Non-CMake Projects. It nails the use case. I'll write up a template based on the recommendations.

Other than sed, is there access to any higher level templating such as python3 based tools like Jinja?

[karelzak]

It would be nice to keep it simple; it means a sed-like solution; just replace @anything@ with real data. See
https://github.com/util-linux/util-linux/blob/master/Makefile.am#L168 for autotools, the same we can do easily in meson.

[t-8ch]

Could you elaborate the advantages of a new CMake script vs FindPkgConfig.cmake?

The only additional feature I see in the linked implementation from Kitware is the construction of an imported target.

But nowadays this can also be done with pkg_check_modules(IMPORTED_TARGET.

[Ryanf55]

Could you elaborate the advantages of a new CMake script vs FindPkgConfig.cmake?

The only additional feature I see in the linked implementation from Kitware is the construction of an imported target.

But nowadays this can also be done with pkg_check_modules(IMPORTED_TARGET.

The goal is regardless of which method chosen, users of LibUUUID only have to call find_package(LibUUID 2.37 CONFIG REQUIRED). The supplied config or module script will handle creating targets under the hood, and handle versioning. For many people, writing custom Find scripts (especially platform portable) is beyond their level of understanding of CMake.

CMake has one here, but it doesn't support version arguments:

• https://gitlab.kitware.com/cmake/cmake/blob/e1409101c99f7a3487990e9927e8bd0e275f564f/Source/Modules/FindLibUUID.cmake

It seems that using PkgConfig already exposes versioning info. I agree, using pkg_check_modules would be my recommended path forward.