Cristian Le via devel wrote: > Coming back to `LIB_SUFFIX` and `*_INSTALL_DIR`, those should have never > been added globally [2]
Why not? LIB_SUFFIX might not be standard, but is used across many projects and has clear semantics. If the project does not use it, it will just ignore it. So why require copying&pasting boilerplate (especially considering that this requires architecture-specific %if hackery)? *_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. > 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. Removing those -D arguments from the %cmake macro is a completely gratuitous backwards-incompatible change that will break a whole bunch of specfiles for no good reason. Kevin Kofler -- _______________________________________________ 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
