F43 Change Proposal: CMake drop non-standard variables (system-wide)

CMake drop non-standard variables

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Drop variables that are not standardized by CMake in the %cmake macro. The dropped options are-DINCLUDE_INSTALL_DIR, -DLIB_INSTALL_DIR, -DSYSCONF_INSTALL_DIR, -DSHARE_INSTALL_PREFIX and -DLIB_SUFFIX. Affected projects are tracked in this copr repo, please check if your packages are failing there.

:link: Owner

:link: Detailed Description

The variables *_INSTALL_DIR, SHARE_INSTALL_PREFIX and LIB_SUFFIX have been passed by default in the %cmake macro, however these variables have never been standardized by CMake, and thus the definition and usage of these variables is up to the individual project, e.g. it is unclear if INCLUDE_INSTALL_DIR is meant to be the absolute or relative path.

Since CMake 3.0, the standardized installation path is defined in GNUInstallDirs and many distributions and packaging environment have been defining their standards in that module. Upstream projects should be migrating to this standard instead.

:link: Migration

Compatibility with fedora releases
Any proposed changes here are compatible with any CMake versions and can be included at any point and backported to any Fedora release.
The corresponding cmake PR will not be merged until the affected packages are patched.

  • As a quick fix, the affected package can manually add the corresponding variables, specifically:

%cmake \ -DINCLUDE_INSTALL_DIR:PATH=%{_includedir} \ -DLIB_INSTALL_DIR:PATH=%{_libdir} \ -DSYSCONF_INSTALL_DIR:PATH=%{_sysconfdir} \ -DSHARE_INSTALL_PREFIX:PATH=%{_datadir} \ %if “%{?_lib}” == “lib64” %{?_cmake_lib_suffix64} \ %endif …

  • Upstream projects can alter the defaults of these variables based on GNUInstallDirs variables, e.g.

project(…) include(GNUInstallDirs) set(LIB_INSTALL_DIR “${CMAKE_INSTALL_LIBDIR}” CACHE PATH “”)

  • To replicate the LIB_SUFFIX the project could use:

include(GNUInstallDirs) if(CMAKE_INSTALL_LIBDIR MATCHES “lib64$”) set(LIB_SUFFIX 64) endif()

:link: Benefit to Fedora

  • Avoid packaging issue due to the current assumption that the the paths used are meant to be absolute paths.
  • Encourage upstream build system modernization and standardization.

:link: Scope

  • Proposal owners:

    • Drop the non-standard CMake variables
    • Try to propose appropriate fixes as much as possible
    • Assist the more complicated migrations and be a point of contact for upstream issue
  • Other developers:

    • Adjust the spec file at least with the minimum quick fix. See Migration.
    • Contact upstream to request/suggest the more long-term solution described in Migration. Change owner is available if upstream requires more specialized CMake discussions.
  • Release engineering: #Releng issue number

  • Policies and guidelines: N/A (not needed for this Change)

:link: Upgrade/compatibility impact

Affected packages would be FTBFS (in the tracked copr repo) and would require patching before the corresponding cmake PR can be merged.

:link: How To Test

A copr repo will be provided with these variables dropped. Use it to try local builds, e.g. using:

copr mock-config lecris/cmake-drop_vars fedora-rawhide-x86_64

If the build is successful, that should be sufficient.

:link: Dependencies

There are currently 309/2359 packages affected gathered and built using mass-pre-build in copr, many of them are previously FTBFS in rawhide.

:link: Contingency Plan

  • Contingency mechanism: N/A (no deadline set)
  • Contingency deadline: No deadline necessary yet
  • Blocks release? No

:link: Documentation

:link: Release Notes

Last edited by @amoloney 2025-04-16T12:10:41Z

Last edited by @amoloney 2025-04-16T12:10:41Z

1 Like

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what you’d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just “+1”. This will make long topics easier to follow.

Please note that this is an advisory “straw poll” meant to gauge sentiment. It isn’t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

Shouldn’t this be targeting Fedora Linux 43?

Updated now, today does not seem to be a good ‘brain day’ for me :woman_facepalming: