Add an unset() command option to remove a variable from the calling
scope, just like the set() command's PARENT_SCOPE option. Teach the
Unset test to cover such cases.
CMake is aware of the policy's NEW behavior and the AppleClang compiler
id. Set the policy to NEW explicitly to avoid the warning and get the
NEW behavior.
Also teach the RunCMake test infrastructure to build tests with
-DCMAKE_POLICY_DEFAULT_CMP0025=NEW to avoid the policy warning
in test output that must match specific regular expressions.
The parent commit introduced a separate "AppleClang" compiler id for
Apple's Clang distribution. Add a policy in order to support projects
that expect this compiler's id to be just "Clang". When the policy is
OLD or not set, map AppleClang back to Clang. Continue to use the
AppleClang id internally while enabling the language, but set the
CMAKE_<LANG>_COMPILER_ID after project() or enable_language() to the
compatible value for use by project code.
Apple distributes their own Clang build with their own version numbers
that differ from upstream Clang. Use the __apple_build_version__ symbol
to identify the Apple Clang compiler and report the Apple Build Version
as the fourth version component in CMAKE_<LANG>_COMPILER_VERSION. Add
Compiler/AppleClang-<lang> and Platform/Darwin-AppleClang-<lang> modules
that simply include the upstream equivalents.
Fix comparisons of CMAKE_<LANG>_COMPILER_ID to Clang in CMake's own
source and tests to account for AppleClang.
Currently, export() is executed at configure-time.
One problem with this is that certain exported properties like
the link interface may not be complete at the point the export() is
encountered leading to an incorrect or incomplete exported
representation. Additionally, the generated IMPORTED_LOCATION
property may even be incorrect if commands following the export()
have an effect on it.
Another problem is that it requires the C++ implementation of cmake
to be capable of computing the exported information at configure time.
This is a limitation on the cleanup and maintenance of the code. At
some point in the future, this limitation will be dropped and more
implementation will be moved from cmTarget to cmGeneratorTarget.
This target type only contains INTERFACE_* properties, so it can be
used as a structural node. The target-specific commands enforce
that they may only be used with the INTERFACE keyword when used
with INTERFACE_LIBRARY targets. The old-style target properties
matching LINK_INTERFACE_LIBRARIES_<CONFIG> are always ignored for
this target type.
The name of the INTERFACE_LIBRARY must match a validity generator
expression. The validity is similar to that of an ALIAS target,
but with the additional restriction that it may not contain
double colons. Double colons will carry the meaning of IMPORTED
or ALIAS targets in CMake 2.8.13.
An ALIAS target may be created for an INTERFACE library.
At this point it can not be exported and does not appear in the
buildsystem and project files are not created for them. That may
be added as a feature in a later commit.
The generators need some changes to handle the INTERFACE_LIBRARY
targets returned by cmComputeLinkInterface::GetItems. The Ninja
generator does not use that API, so it doesn't require changes
related to that.
6a47c37 add_test: Mention generator expressions in old-style add_test docs
d331292 cmTestGenerator: Evaluate generator expressions in test properties
6fe5c4a cmTestGenerator: Separate test properties for each configuration
6931999 VS6: Add some delimiting between error message and content.
d1a5f12 cmTarget: Fix typo in comment.
961c0ba Fix comments to match the code.
7cca50c Remove unused include.
This commit adds the ability to ccmake of cycling through cache options.
This uses the STRINGS property of the cache entry. The enter key will cycle
forward, and the right and left arrows will go up and down in the list.
Re-insert the semicolon which was removed during splitting.
Commit d777b8e7 (Genex: Allow relative paths in INSTALL_INTERFACE.,
2013-07-25) introduced the prefixItems method to allow relative paths
in the argument of the INSTALL_INTERFACE expression. That method was
buggy in that it did not re-introduce the semicolon separator in
the result.
This bug also affects paths which are already absolute in user code.
Some compilers try to simulate other compilers as a drop-in replacement
supporting all the same command-line options and predefined preprocessor
macros. In such cases it will be useful to have CMake load the compiler
information files for the simulated compiler instead of duplicating the
information. Teach CMakeDetermineCompilerId to extract the simulated
compiler id and version when the compiler id detection provides it.
Move the cmake::ExecuteCMakeCommand static method and all the static
methods it calls out of the 'cmake' class to a separate 'cmcmd' class.
Build the latter as part of the main cmake executable with cmakemain.cxx
and not in CMakeLib. Drop unused header includes from "cmake.cxx".
By moving this implementation out of cmake.cxx we avoid carrying it
around in all the executables that use class 'cmake'. It is needed only
for the main "cmake -E" functionality.
Xcode 2.1 through 4 supported $(CURRENT_ARCH) in a PBXFileReference
'path' value used in the "Link Binary with Libraries" build phase.
CMake uses this to reference object file locations on link lines to
bring in OBJECT library content. However, Xcode 5 now evaluates the
$(CURRENT_ARCH) reference in this context as "undefined_arch" so the
wrong path is given to the linker. There seems to be no alternative way
to produce an architecture-specific value in a PBXFileReference.
Fortunately Xcode 5 now also handles link dependencies for paths linked
through OTHER_LDFLAGS. For Xcode >= 5, move the OBJECT library object
file references from the link build phase to OTHER_LDFLAGS. We can
still show the object files in the source group listing in either case.
Xcode 5.0 now computes dependencies from files linked through
OTHER_LDFLAGS, so we no longer need the XCODE_DEPEND_HELPER hack to
re-link dependents when targets change.
In buggy code like
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
MAIN_DEPENDENCY ${CMAKE_CURRENT_SOURCE_DIR}/out.h.in
...)
add_custom_command(
OUTPUT ${CMAKE_CURRENT_BINARY_DIR}/out.h
...)
that has more than one rule to generate the same output CMake has always
used the first rule. However, since commit 2268c41a (Optimize custom
command full-path dependency lookup, 2013-08-06) we update the map from
output to cmSourceFile for every rule generating an output, effectively
keeping the last command instead of the first.
Fix this regression by checking for each map update if the output
already has an entry. If so, keep only the original entry. The VS 8
generator triggers this with a special case for generate.stamp rules
that differ between ZERO_CHECK and normal targets, so do not warn for
now. Leave a TODO comment for warning in the future.
Multiple libraries in a single buildsystem can be exported to multiple
export-sets.
If a library from one export set depends on a library from
another export set, the export logic generates a check in the targets
file to verify that the target in the other export set is found. That
check is executed at downstream-find_package-time.
However, a target may depend privately on a target in another export
set. In that case, the depend used to also be listed in the required
targets in the targets file. Change the export logic to ignore the
private link entries instead.
Resolve conflict in Source/cmTestGenerator.cxx by taking "their" side
(test-property-genex). It already accounts for the lower-case change in
"our" side (generate-modern-style).
The old-style add_test() call does not support generator expressions at
all. This also applies to the properties for the test, but it is not
mentioned at all.
This is useful for cases like:
add_test(NAME mytest COMMAND mydriver $<TARGET_FILE:myexe>)
set_tests_properties(mytest PROPERTIES
REQUIRED_FILES "$<TARGET_FILE:myexe>"
WORKING_DIRECTORY "${CMAKE_CURRENT_BINARY_DIR}/$<CONFIGURATION>"
)
In this example we require the actual test executable to exist to
run the test in addition to the test driver at argv[0]. Also the
$<CONFIGURATION> expression improves over \${CTEST_CONFIGURATION_TYPE}
because the latter is not normalized for case-sensitive filesystems.
Move property generation from GenerateScriptConfigs to separate copies
in GenerateOldStyle and GenerateScriptForConfig. This causes the
per-config tests generated for the add_test(NAME) signature to each get
their own test properties. This will allow us to later change the
property values based on the test configuration.
While at it, generate lower-case CMake code (e.g. set_tests_properties).
Inspired-by: Ben Boeckel <mathstuf@gmail.com>
State explicitly that the dependencies will build before the target.
Drop wording that may imply the opposite.
Suggested-by: Rob Stewart <robert.stewart@sig.com>
Teach cmListFileLexerDestroy to call cmListFileLexerSetToken with a NULL
token to free the token string buffer. Without this, if an error occurs
before the token cleanup happens when EOF is reached, then the token
string buffer may leak.
Only one argument is required. Also avoid using the same variable name twice in
the input list and follow the convention used elsewhere for optional arguments.
Similar incomplete generator expressions are already tested
in the GeneratorExpression unit test, but those are executed
with add_custom_target. The generator expressions in the include
directories are run through the preprocessor, whereas the ones
run through add_custom_target are not.
