Age | Commit message (Collapse) | Author |
|
This will be available in CMake 3.0.0. This way, we automatically pick
up any new features from it.
REVIEW: 115775
|
|
All the frameworks are ported now, so this is no longer necessary.
Checked by building everything with kdesrc-build.
|
|
Now that we no longer have to support the old syntax, some of the
more complex bits of the argument parsing can be removed.
REVIEW: 115869
|
|
Overriding a CMake package like this will just cause all sorts of
headaches later on. In this particular case, projects that depended on
CMake 2.8.13 or later (more likely 3.0.0) would fail with a message
about removing the CMakePackageConfigHelpers file, but would have no way
to do that while still using ECM.
This also renames the configure_package_config_file() macro to
ecm_configure_package_config_file(), so that anything including
CMakePackageConfigHelpers afterwards does not overwrite the macro
unexpectedly.
For now, we keep a CMakePackageConfigHelpers.cmake file that just wraps
ecm_configure_package_config_file() as configure_package_config_file()
to keep the frameworks building while they are ported.
REVIEW: 115496
Reviewed by Sune Vuorela <kde@pusling.com>
|
|
[at least everything that kdesrc-build builds. If there's something else,
then it should be added to kdesrc-build...]
|
|
ecm_generate_headers() now allows/forces the caller to collect the paths
of the generated headers, so that they can be passed to the install
command. This avoids issues of unexpected files being in the CamelCase
includes directory, both from previous builds and because of
case-insensitive file systems.
MODULE_NAME is removed, as it is no longer desirable or necessary.
Instead, the headers are placed directly in the output directory
(usually CMAKE_CURRENT_BUILD_DIR).
Overall, this makes ecm_generate_headers() behave much more like other
file generation macros (like the Qt ones).
The old syntax is still supported for now, to make the porting effort
easier.
REVIEW: 115765
|
|
Reviewed by: alexmerry
|
|
ECM_GENERATE_PRI_FILE() creates a .pri file for a library so that qmake-based
apps can more easily use the library.
It also sets ECM_MKSPECS_INSTALL_DIR as the directory to install the .pri file to.
REVIEW: 115099
|
|
This makes it easier for other functions to access the project version,
for instance my upcoming ECM_GENERATE_PRI_FILE()
|
|
This behaviour can be overriden by passing the GUI flag to the command
REVIEW: 115211
|
|
REVIEW: 114888
|
|
version
This is all internal, doesn't change the API or effects of ecm_setup_version.
|
|
headers
|
|
RELATIVE is needed because some projects have their headers (and sources)
split into different subdirectories.
REQUIRED_HEADERS gives the opportunity to receive a list of all the headers
we're depending on, in case the user wants to re-use it.
|
|
Create ECM_GENERATE_HEADERS, a cmake function that will generate the
forward headers like we used to, in cmake configure time.
REVIEW: 113406
|
|
REVIEW: 113522
|
|
I can't find any use of it, which is semi-expected. It is replaced
by CMakePrintHelpers.cmake in CMake upstream.
|
|
REVIEW: 113483
|
|
These are not used anywhere.
|
|
|
|
ecm_add_test was renamed eventually, but all uses weren't adapted
|
|
Every framework in KF5 has a macro similar to these, this reduces
the unnecessary duplication inside all of the frameworks
REVIEW: 112828
|
|
|
|
|
|
|
|
Accept a single version argument instead of three. The old signature
will be an error in a few days.
|
|
Both macros are obsoleted by ecm_setup_version.
REVIEW: 112665
|
|
Add a macro for finding dependencies. It should be in a future
version of CMake. Finding dependencies is one of the major missing
pieces of KF5 Config files.
|
|
|
|
|
|
|
|
|
|
Make FindQt5Transitional.cmake handle this transparently.
REVIEW: 107438
|
|
Alex
|
|
This commit
-adds the macro ecm_setup_version(), as proposed on the kde-frameworks list
-sets CMAKE_INSTALL_DEFAULT_COMPONENT_NAME to ${PROJECT_NAME} if a project has been set
-makes e-c-m require cmake 2.8.10.1
Alex
|
|
"Can you please rename it to ECMDBusAddActivationService.cmake and
the contained macro to ecm_dbus_add_activation_service(), so it follows the
naming conventions in cmake (macro has the same name as the file) and ecm (all
macros have the prefix ecm)." -> Done.
Nothing to adapt in kdelibs-frameworks yet, it has its own copy for now
(I'll get rid of it at the next ECM version upgrade).
|
|
|
|
My addition of major/minor/patch included a copy/paste error (double-quotes)
and the all-in-one version number (like QT_VERSION and KDE_VERSION) was
missing, added now.
|
|
Wrote full docu for it, and then aseigo pointed me to a wiki page
that had it all already...
http://techbase.kde.org/Development/Tutorials/D-Bus/Autostart_Services
|
|
(and for plugin-loading version number handling)
|
|
kdelibs for the new file ECMWriteVersionHeader.cmake)
Alex
|
|
foo_version.h
The plan is strip this out of ECMQtFramework.cmake, then ECMQtFramework.cmake will be basically only deal with those Config.cmake files.
Alex
|
|
|
|
|
|
|
|
Alex
|
|
|
|
As discussed, remove the LIBRARY_TYPE cmake variable and
put BUILD_SHARED_LIBS instead into the cache, set to TRUE.
So if somebody wants to build a static library, and the project
allows it (by not explicitely using "STATIC" in add_library()), he
can switch this variable to FALSE in the cache.
Also, put the ARCHIVE library component into the Devel install component,
static libs and Windows lib files belong to the development package.
Use newer write_basic_package_version_file() instead of older write_basic_config_version_file(),
which are identical beside the name
Alex
|
|
Alex
|
|
-rename the cmake package from extra-cmake-modules to ECM
-change variable names and docs accordingly
-move setting of Qt-related defines from ECMQtFrameworks.cmake to KDECompilerSettings.cmake
-remove ECMSetVersionVariables.cmake, we'll do it some other way
-rename ECMConfig.cmake.in to ECMQtFrameworkConfig.cmake.in, since this is where it is used, and it would have the same name as ECMConfig.cmake.in which is for extra-cmake-modules itself
Alex
|