| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
|
|
|
|
David Faure and Patrick Spendrin have convinced me that NAME_PREFIX
should be informational only, and not be used to prevent clashes, since
it makes things confusing when you run tests manually.
This is a SIC change (although in practice only kio and kconfig should
be affected, currently).
REVIEW: 118768
CCMAIL: kde-frameworks-devel@kde.org
CCMAIL: kde-buildsystem@kde.org
|
|
While the tests in ECM are not "built" as such (at least, not until they
are run), disabling the tests might be desirable to avoid the compiler
checks and to make the whole build process architecture-independent.
REVIEW: 118498
|
|
Setting the language for ECM's project() call to C had unanticipated
side-effects - notably that the installed version file required the
architecture to match the one used at build time.
Instead, we make the tests a sub-project, setting up C as the language
there (since most of the tests do use C, albeit slightly indirectly).
REVIEW: 118498
|
|
Move the detailed testing of KDEInstallDirs from ExecuteKDEModules to a
subdir of KDEInstallDirsTest. This is where you would expect to find it,
and it also makes sure that other KDE modules are not affecting the
test.
This also makes the KDEInstallDirs/not_cache_variable regression test
work the same way as the other tests, doing a double-configure and
build. While not stricly necessary to catch the original issue, it does
ensure that the problem does not appear when reconfiguring either.
|
|
|
|
Although ECM does not make use of a compiler directly, the language
affects the search path for CMake packages; in particular, a package
installed to /usr/lib64/cmake will not be found if NONE is passed as the
language argument to project(). This meant that a 64-bit version of
Qt5LinguistTools would not be found on systems where 64-bit libraries
are not installed in the "default architecture" location (/usr/lib).
With this change, the configure step performs some otherwise-unnecessary
tests. We minimise this by explicitly specifying the C language (which
is also what some of the tests use), rather than letting it be the
default (which is C and C++).
REVIEW: 118374
|
|
REVIEW: 118216
|
|
REVIEW:118147
|
|
REVIEW: 118127
|
|
- Test calling ecm_process_po_files_as_qm() without INSTALL_DESTINATION argument
- Test calling ecm_install_po_files_as_qm() with CMAKE_INSTALL_LOCALEDIR set
and with LOCALE_INSTALL_DIR set
REVIEW: 118114
|
|
This matches how CMake's GNUInstallDirs does things.
REVIEW: 118057
|
|
|
|
This reverts commits
b90b64632f46e929f26ab9a4ee0033478febe0eb
ba8600088b8838d5453dd0990ec595e904ec216e
554be62af6d0f01049985076b2445229bae41816
These were causing configure failures in frameworks that use
ECMAddTests.
CCMAIL: ps_ml@gmx.de
CCMAIL: kde-frameworks-devel@kde.org
|
|
|
|
|
|
|
|
http://techbase.kde.org/Projects/KDE_on_Windows/kf5/meetingnotes-2014-05-06
|
|
This way, overriding LIBEXEC_INSTALL_DIR will change where frameworks
install libexec files in the expected way.
REVIEW: 118048
|
|
This is needed for e.g. kpluginfactorytest in kcoreaddons. Plugins are
searched relative to the directory containing the running executable and
before this commit the unit test was in ${CMAKE_BINARY_DIR}/bin and
the plugin dll in ${CMAKE_BINARY_DIR}/lib, which meant that it could not be
found. This was not a problem on Linux since there the unit test and the
plugin .so ends up in ${CMAKE_CURRENT_BINARY_DIR}.
Reviewed on #kde-windows
|
|
ecm_create_qm_from_po_files() was actually not very useful in practice.
So that is deprecated, to be removed before ECM 1.0.
Instead, the ECMPoQmTools provides several useful functions:
ecm_create_qm_loader() (which already existed in
ECMCreateQmFromPoFiles), ecm_process_po_files_as_qm() (which has the
same signature as gettext_process_po_files() from the FindGettext
module) and ecm_install_po_files_as_qm(), which is a convenience
function mostly for the benefit of KDE Frameworks (although potentially
useful for whatever other projects have the unusual requirement of a
Gettext translation workflow but no Gettext usage in the code).
NB: some clean-up to the documentation was done by Alex Merry
<alex.merry@kde.org> as part of this commit.
REVIEW: 117823
|
|
use CMAKE_[RUNTIME|ARCHIVE|LIBRARY]_OUTPUT_DIRECTORY. dlls and executables are built into the bin subdir and import & static libraries and plugins end up in the lib subdir of the build directory.
REVIEW:117965
|
|
REVIEW: 117682
|
|
|
|
in the path
|
|
This essentially reverts db553c810cbc3a446f90d4c962110d6262853cde. It
turns out that (for better or worse) quite a few places access files
without going through KFile, so it is worth making sure they can deal
with files larger than 2Gb on 32-bit systems.
Reviewed by: Harald Sitter <sitter@kde.org>
CCBUG: 165449
|
|
REVIEW: 117935
|
|
REVIEW: 117907
|
|
|
|
This is where applications install plugins, so "kf5" is incorrect.
Software should use application- or framework-specific directories
(which may or may not be versioned).
|
|
Also provide a subdirectory specific to kf5 that will put them in
lib/libexec/kf5
|
|
|
|
KNotifications will look here for .notifyrc files.
|
|
kde5/services is kservices5
kde5/servicetypes is kservicestypes5
|
|
This provides versioning in a way that is simple to update for KF6, and
reduces our footprint in /usr/share.
|
|
Only frameworks should be installing in include/KF5. They use
KF5_INCLUDE_INSTALL_DIR, which has the KF5 suffix, while other code
should install to just include (or a subdirectory of their choice).
|
|
Currently, this is the same as INCLUDE_INSTALL_DIR, but
INCLUDE_INSTALL_DIR will lose the "KF5" suffix once the frameworks are
changed to use KF5_INCLUDE_INSTALL_DIR. Because INCLUDE_INSTALL_DIR is
used in INSTALL_TARGETS_DEFAULT_ARGS, there is now also a
KF5_INSTALL_TARGETS_DEFAULT_ARGS.
|
|
The ecm sphinx module occasionally tried to modify a list it was
iterating over, which is a Bad Thing and raised an exception on the
third or so time it was run without clearing the build directory.
|
|
REVIEW: 117780
|
|
cmake_policy() does not allow you to reference policies that do not yet
exist, so include a version check.
|
|
ecm_dbus_add_activation_service() requires suffient knowledge of its
internals to use that replacing two lines with one seems silly.
In order to use it you have to know it behaves like configure_file()
(because you have to construct the file yourself), except that it also
installs it somewhere (for which you have to make sure
DBUS_SERVICES_INSTALL_DIR is defined before you use it, which is
certainly not a given for non-KDE projects). By this point, why not just
use configure_file() and install()? The DBUS_SERVICES_INSTALL_DIR
provided by KDEInstallDirs is all the magic you actually need, and if
that's explicit in the CMakeLists.txt file, it's a lot more obvious that
you should have it defined somewhere.
REVIEW: 117581
|
|
Find module tests now use find_package(), and there is a version for
when CMAKE_MODULE_PATH is set and a version for when
ecm_use_find_modules() is used.
KDE modules are also now tested.
REVIEW 117658
|
|
ECMUseFindModules allows find modules to be copied to a local directory.
These find modules may use ECMFindModuleHelpers, but they will not be in
the same relative location to ECMFindModuleHelpers.cmake and there is no
guarantee that ECMFindModulesHelpers.cmake will be in the CMake module
path.
To solve this, we make sure there is always a stub file in the same
directory as the find modules that includes the real
ECMFindModuleHelpers.cmake. The one installed with ECM just includes
"../modules/ECMFindModuleHelpers.cmake", while ecm_use_find_modules
generates a stub that uses an absolute path.
REVIEW 117658
|
|
When CMake policy CMP0048 (CMake 3.0) is set to NEW, the project()
command is meant to manage the project's version variables. We therefore
do not set the PROJECT_VERSION variables in this case.
To make sure projects do not have to specify their version in multiple
places, this also allows the keyword "PROJECT" to be passed to
ecm_setup_version instead of an actual version number. In this case, the
version passed to project() will be used.
REVIEW: 117619
|
|
This requires the icon files to be specified (which is better than
globbing, because the build system will then be able to tell when files
are added or removed and re-run CMake).
It also removes the theme name from the filename pattern: the old code
used a shorthand theme name for a small number of themes, and didn't
allow any other themes. Extending this to arbitrary themes could cause
problems with themes that have numbers or hyphens (or whatever other
delimiter character was used) in their names. Most users are likely to
just want to install to a single theme anyway (based on a random
sampling of users of kde4_install_icons), so that is what the new syntax
requires.
The old syntax still works and behaves as before.
ecm_update_iconcache is renamed to _ecm_update_iconcache - it was never
documented as public API anyway.
REVIEW: 117617
|
|
Rather than blindly using ${LIB_INSTALL_DIR} and ${INCLUDE_INSTALL_DIR}
(which assume the inclusion of KDEInstallDirs), this checks whether they
exist, also checks for ${CMAKE_INSTALL_LIBDIR} and
${CMAKE_INSTALL_INCLUDEDIR} (set by GNUInstallDirs), provides hard-coded
defaults and allows arguments to be used to override the values.
This should make it useful to projects that aren't KDE Frameworks.
REVIEW: 117593
|
|
The traditional *_LIBRARIES, *_INCLUDE_DIRS and *_DEFINITIONS do have
some uses - they make it easier to create package config files that use
found libraries in their link interface. So this makes sure these
variables are set by ecm_find_package_handle_library_components() (and
hence by FindWayland.cmake and FindXCB.cmake).
REVIEW: 117585
|
