This defines global, directory, and target properties
RULE_LAUNCH_COMPILE, RULE_LAUNCH_LINK, and RULE_LAUNCH_CUSTOM. Their
values specify 'launcher' command lines which are prefixed to compile,
link, and custom build rules by Makefile generators.
When testing whether to re-run CMake, a byproduct may be a symlink. If
so, the existence of the link is important rather than the link's
target. See issue #8465.
App Bundle and Framework directories, symlinks, and Info.plist files we
create during generation are byproducts, not outputs. We should re-run
CMake only when they are missing, not when they are old.
See issue #8465.
This teaches cmMakefile::GetProperty and cmake::GetProperty methods to
return NULL when the property name is NULL, making them more robust and
consistent with the behavior of cmTarget::GetProperty.
OpenBSD shared libraries use a ".so.<major>.<minor>" extension and do
not have a symlink with just a ".so" extension. Its "ld" is capable of
finding the library with the best version. This change adds support for
finding such libraries. See issue #3470.
The set_property command unsets a property if it is given no value. In
the case of GLOBAL properties, the cmake::SetProperty method would
replace a NULL value with "NOTFOUND". Instead it should be left as NULL
so that the property is unset as expected. Once it is unset the
get_cmake_property command will still report NOTFOUND while the
get_property command will return the empty string as documented.
- We used to always put LIBRARY_OUTPUT_PATH and EXECUTABLE_OUTPUT_PATH
in the cache if the project did not.
- In CMake 2.6 these variables should no longer be used.
- Now add them only if CMAKE_BACKWARDS_COMPATIBILITY is also cached.
- This happens only when CMP0001 is set to OLD or WARN or if
the user or project sets it. In any case compatibility is needed.
- Reported by Miguel A. Figueroa-Villanueva and Philip Lowman.
the argument after -Wno-dev was skipped, which happened to be the source
directory, and so the current working directory was assumed as source
directory, although it was the build directory (maybe this didn't have an
effect if there was already a CMakeCache.txt in the build dir)
Alex
- CMake 1.8 and below did not do the check but could get in
infinite loops due to the local generate step.
- CMake 2.0 added the check but failed to perform it in directories
with no targets (see bug #678).
- CMake 2.2 removed the local generate which fixed the problem but
did not remove the check.
- Between CMake 2.4 and 2.6.0rc6 the check was fixed to work even
when no targets appear in a directory (see bug #6923).
- Bottom line: the check is no longer needed.
- Add cmListFileBacktrace to record stack traces
- Move main IssueMessage method to the cmake class instance
(make the backtrace an explicit argument)
- Change cmMakefile::IssueMessage to construct a backtrace
and call the cmake instance version
- Record a backtrace at the point a target is created
(useful later for messages issued by generators)
- ZERO_CHECK should check all stamps in case
of parallel build (fixes complex test failure)
- ZERO_CHECK should not appear when
CMAKE_SUPPRESS_REGENERATION is on (fixes bug 6490)
- Remove CMP_0001 (no slash in target name) and restore
old CMAKE_BACKWARDS_COMPATIBILITY check for it
- Replace all checks of CMAKE_BACKWARDS_COMPATIBILITY
with cmLocalGenerator::NeedBackwardsCompatibility calls
- Create new CMP_0001 to determine whether or not
CMAKE_BACKWARDS_COMPATIBILITY is used.
(old = use, new = ignore)
- Show CMAKE_BACKWARDS_COMPATIBILITY in cache only when
CMP_0001 is set to OLD or WARN
- Update documentation of cmake_policy and cmake_minimum_required
to indicate their relationship and the 2.4 version boundary
- When no cmake policy version is set in top level makefile
implicitly call cmake_policy(VERSION 2.4) which restores
CMAKE_BACKWARDS_COMPATIBILITY and other 2.4 compatibility
- Fix tests MakeClean and Preprocess to call
cmake_policy(VERSION 2.6) because they depend on new policies
- Cycles may be formed among static libraries
- Native build system should not have cycles in target deps
- Create cmComputeTargetDepends to analyze dependencies
- Identify conneced components and use them to fix deps
- Diagnose cycles containing non-STATIC targets
- Add debug mode property GLOBAL_DEPENDS_DEBUG_MODE
- Use results in cmGlobalGenerator as target direct depends
Brad King
Bill Hoffman
David Cole
Alexander Neundorf
Ken Martin