| Age | Commit message (Collapse) | Author |
|---|
|
REVIEW: 128780
|
|
In particular, strongly recommend looking at the equivalent CMake
documentation with regard to PATH_VARS, as a lot of projects that should
be making use of it are not.
|
|
|
|
REVIEW: 120655
|
|
This is deliberately modelled very closely on CMake's documentation
system. It's a hefty patch, because it involved changing all the
documentation to be in reStructuredText format. I also cleaned up the
copyright/license statements at the same time.
Note that the find modules contain the full license, due to the fact
that ecm_use_find_module() copies them out of the ECM distribution.
|
|
Specifically, we namespace the variables to avoid conflicts, and make
the version argument optional.
REVIEW: 116080
|
|
This will be available in CMake 3.0.0. This way, we automatically pick
up any new features from it.
REVIEW: 115775
|
|
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>
|
