GitLab

The main target consumers of this macro currently (should) want to be
informed about new deprecations as early as possible. As do the authors
of the warnings.

So instead let's make no warnings an opt-in. Not documenting the
now deprecated flag in the docs, given no wide-spread use yet, just
supporting still in the code with a note to users.

This got messed up when refactoring the value from an one-value-keyword to an option.

This should catch undefined preprocessor expressions, i.e. instead of
showing a warning if FOO_BAR_H is undefined:
 #if FOO_BAR_H

make the build fai lwith an error instead.

This combined with using #cmakedefine01 (instead of #cmakedefine), could
catch things like:
pim/kdepim-runtime@05a0e5bb

NO_CHANGELOG

Complements 6f8e9ff8

NO_CHANGELOG

Should help readers being aware of pitfalls

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

NO_CHANGELOG

The message read odd with the missing be

Christoph Cullmann authored May 20, 2022 and David Faure committed Jun 06, 2022

OpenBSD has a similar patch inside the ports, see

Allow KDE5 libraries to be built without having to link to libc explicitly.
Index: kde-modules/KDECompilerSettings.cmake
--- kde-modules/KDECompilerSettings.cmake.orig
+++ kde-modules/KDECompilerSettings.cmake
@@ -530,6 +530,8 @@ endfunction()
 # Better diagnostics (warnings, errors)
 ############################################################

+set(ALLOW_UNDEFINED_LIB_SYMBOLS No CACHE BOOL "allow undefined symbols in generated shared objects")
+
 if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPLE) OR
         (CMAKE_CXX_COMPILER_ID MATCHES "Clang" AND NOT APPLE) OR
         (CMAKE_CXX_COMPILER_ID STREQUAL "Intel" AND NOT WIN32))
@@ -537,9 +539,11 @@ if ((CMAKE_CXX_COMPILER_ID STREQUAL "GNU" AND NOT APPL
     set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_SHARED_LINKER_FLAGS}")
     set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--fatal-warnings ${CMAKE_MODULE_LINKER_FLAGS}")

-    # Do not allow undefined symbols, even in non-symbolic shared libraries
-    set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
-    set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+    if (NOT ${ALLOW_UNDEFINED_LIB_SYMBOLS})
+        # Do not allow undefined symbols, even in non-symbolic shared libraries
+        set(CMAKE_SHARED_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_SHARED_LINKER_FLAGS}")
+        set(CMAKE_MODULE_LINKER_FLAGS "-Wl,--no-undefined ${CMAKE_MODULE_LINKER_FLAGS}")
+    endif()
 endif()

 set(_KDE_GCC_COMMON_WARNING_FLAGS "-Wall -Wextra -Wcast-align -Wchar-subscripts -Wformat-security -Wno-long-long -Wpointer-arith -Wundef")

Given ECM is released tightly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.

Friedrich W. H. Kossebau authored Jun 01, 2022 and Christophe Giboudeaux committed Jun 02, 2022

Given ECM is released tighly bundled with KF, which itself requires
Qt 5.15 now, and no Linux distribution is known by repology.org which
ships older Qt, but current ECM, that support is considered of no more use.

The use of set_package_properties() requires the include, which might
not have been done by the macro consumer.

If the module is not included, the current message would be misleading.

Including the module by default is undesirable, because we print out a warning
that we do not override an existing module. While this warning is reasonable in most
cases, it is annoying for projects that have a custom clang-format file.

Checking if a .clang-format file exists and if not including KDEClangFormat is fragile,
because it depends on the include order of the modules.

Considering all that, a proper warning with instructions on how to fix the issue
is IMHO the best way to go.

I was getting CMake errors in repositories that had a pre-existing commit
hook: `string sub-command FIND requires 3 or 4 parameters.`
Adding quotes around the variables from 6224e7b8
fixes this issue for me.

Julius Künzel authored Apr 23, 2022 and Volker Krause committed Apr 23, 2022

@aacid related to your MR !245

QQmlImportDatabase::resolvePlugin doesn't accept lib prefixes under
Windows, causing to fail to import when using as a dynamic plugin.

Inspired by kirigami!34

Allows us to avoid using source variables.

Allows us to avoid using source variables.

Ahmad Samir authored Apr 15, 2022 and Christophe Giboudeaux committed Apr 15, 2022

This means removing the find_program() logic, since it was only useful if
we don't want to make CMake spend time finding a compiler; so it was only
useful for building modules that don't need a compiler at all, wallpapers,
icon themes ...etc; so find_program() is only useful when it comes before
the find_package() and enable_language() calls. Thanks to Christophe
Giboudeaux for the explanation. This might make the build time for such
modules a tiny bit longer, but it's worth it to make finding qmake/qtpaths

If the .git/hooks/pre-commit already exists, only add the clang-format line
if it doesn't already exist.

If clang-format isn't found, there is nothing to write to the file.

Fix finding qmake when executable has no version suffix

Like is done in the Qt5 qmake code path.

Some applications look for ECM and need to know Qt paths but
don't need to link to anything. That's the case for icons or
wallpapers.

For these cases, ECMQueryQt will first try to find qmake or
qtpaths before looking for Qt CMake config files.

Also handle cases where project() sets 'LANGUAGE' to 'NONE'.
The CXX language needs to be enabled for find_package to look
for Qt into library dirs.

If the tests use Qt we need to forward the Qt major version option
as well.