On 2025/03/18 0:56, Kevin Kofler via devel wrote:
Cristian Le via devel wrote:
Coming back to `LIB_SUFFIX` and `*_INSTALL_DIR`, those should have never
been added globally [2]
Why not?
All of those, similar to `CMAKE_POLICY_VERSION_MINIMUM` hide an
underlying issue that should have been reported to upstream early on. In
this case it's that GNUInstallDirs has long been the de-facto standard
which distros already make use of to specify their filesystem standard.
As an upstream first, we should encourage upstream projects to the
better standards, and only add workarounds as a case-by-case basis, not
globally.
*_INSTALL_DIR, on the other hand, has a specification, it comes from KDE 4:
https://cmake.org/pipermail/cmake-developers/2012-January/014637.html
– deprecated by KDE, but still in use in a lot of non-KDE CMakeLists.txt
files.
Reading this, it doesn't seem to have been a standard defined and used
by CMake, and the naming convention is so generic, you cannot assume
that the package is intentionally using that specification or it is just
a name clash. Instead if we do not enforce it, the packagers can
double-check what the intent of those variables are and track a RFE
issue for modernization.
There was an example with `libspatialindex` [3] where `LIB_INSTALL_DIR` is
meant to be relative path, not an absolute path,
That is an upstream bug. LIB_INSTALL_DIR can be either absolute or relative.
(See the link, which gives an absolute path as the default value for
LIB_INSTALL_DIR, whereas some other *_INSTALL_DIR variables have relative
default paths. This comes from CMake itself accepting both absolute and
relative paths in the install command.) Any CMakeLists.txt making
assumptions one way or the other is broken and needs to be fixed.
Upstream was careful enough to provide GNUInstallDirs based defaults
such that the packager never needs to specify those variables unless
they want to overwrite them. If we don't provide our variables, there is
no need for patching and workarounds as it works out-of-the-box. The
CMAKE_INSTALL_* variables and derived are meant to be used as relative
first and convert them to absolute paths as needed via
GNUInstallDirs_get_absolute_install_dir, but not the other way around.
It would be unfair to require upstream to support that pattern when
CMake does not provide the tools to do so (I know about approaches with
$<PATH:IS_RELATIVE> and configure_package_config_file(PATH_VARS), but
these are not easy to adapt and support for older versions).
<https://cmake.org/cmake/help/latest/module/GNUInstallDirs.html#command:gnuinstalldirs_get_absolute_install_dir>
--
_______________________________________________
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam, report it:
https://pagure.io/fedora-infrastructure/new_issue
