This is needed in the case that Automoc is used, as that calls
GetIncludeDirectories, which may cache the resulting include dirs
too early in the generate step.
Also, because the automoc step is so early, we can't cache the
include directories at that point. At that point the build interface
of all dependencies are not populated yet, so we'd be caching the
includes before appending the build interface. Only start caching
when we're definitely generating the buildsystem. At that point, the
includes should be stable.
We still need to invoke AppendBuildInterfaceIncludes
in the GlobalGenerator because the build interface includes affect
mostly the dependencies of targets (such as the automoc targets),
rather than the targets themselves, so the build interface needs
to be appended for all targets before generation is done.
All ctest --build-and-test invocations require the options
--build-generator ${CMAKE_GENERATOR}
--build-makeprogram ${CMAKE_TEST_MAKEPROGRAM}
to be passed and have consistent values, except for a few special cases.
Collect the generator options in a variable instead of repeating the
options everywhere explicitly.
Implement generator toolset selection (cmake -T) for VS >= 10 by setting
the PlatformToolset. Extend the RunCMake.GeneratorToolset test case to
verify CMAKE_GENERATOR_TOOLSET when the generator supports -T.
Since commit 485a940e (VS: Simplify MSVC version reporting, 2012-08-23)
all MSVC version information is detected during the compiler id step
from the actual compiler invoked by generated build systems rather than
hard-coded in VS generators. Therefore we can set the PlatformToolset
in VS >= 10 project files and support toolsets from other VS versions.
Reject the option by default. It will be implemented on a per-generator
basis. Pass the setting into try_compile project generation. Add cache
entry CMAKE_GENERATOR_TOOLSET and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorToolset test to cover basic "-T" option cases.
Verify that CMAKE_GENERATOR_TOOLSET is empty without -T, that -T is
rejected when the generator doesn't support it, and that two -T options
are always rejected.
We need to make sure expressions which evaluate TARGET_PROPERTY:TYPE
multiple times for example get the correct result each time, and
not an empty string instead.
Teach CMakeParseImplicitLinkInfo to convert implicit link library full
paths to a canonical form. This makes them more reproducible in case
different language compiler front-ends add the same library by different
paths e.g. ".../libA.a" and "...//libA.a".
Add a case to the CMake.ImplicitLinkInfo test to cover removal of extra
slashes from both library and directory paths.
e48d842 Cache context-independent includes on evaluation.
089fe1c Optimize genex evaluation for includes and defines.
179f495 find_package: Reword <package>_NO_INTERFACES documentation
e7b579b Test workaround of bad interface include directories from depends.
77cecb7 Add includes and compile definitions with target_link_libraries.
0b92602 Add the $<LINKED:...> generator expression.
0fa7f69 Add API to check if we're reading a includes or defines property.
2c3654c Add a way to exclude INTERFACE properties from exported targets.
d4297d5 Export targets to a targets file, not a Config file.
df4d2b2 Make it an error for INSTALL_PREFIX to be evaluated.
7ceeba9 Advance more when preprocessing exported strings.
30268b4 Handle reading empty properties defined by the link interface.
5484c60 Merge branch 'vs6-rule-files' into add-ExternalData-module
1fd8d01 ExternalData: Attach download rules to content links in IDEs
a6d3ffc Fix Module.ExternalData test on VS 6
aed590a Fix Module.ExternalData test on Cygwin
06e8ded Merge branch 'fix-atomic-rename-on-Windows' into add-ExternalData-module
e2e0d2e ExternalData: Collapse ../ components in DATA{} paths
ee2abfd ExternalData: Add support for SHA 1 and 2 hash algorithms
aa8b228 ExternalData: Generalize hash algo/ext handling
9e518a8 ExternalData: Allow DATA{} syntax to reference directories
175ed02 ExternalData: Allow ()-groups in series match regex
4befecc ExternalData: Add tests covering interfaces and errors
bcd2580 ExternalData: Improve series matching using an explicit syntax
c0cebcb ExternalData: Remove unused private interface
5275993 ExternalData: Cleanup stray TODO and typo in comments
7bb8344 ExternalData: Do not match directory names when resolving DATA{}
00d801f ExternalData: Remove compatibility with CMake < 2.8.5
...
Run the test with the ctest --build-noclean option. The test
CMakeLists.txt file already uses file(REMOVE_RECURSE) to clean out
downloaded data anyway. Some file removed by "msdev ... /clean" causes
CMake to re-run in the middle of the build step and file(REMOVE_RECURSE)
wipes out already-generated files.
This establishes that linking is used to propagate usage-requirements
between targets in CMake code. The use of the target_link_libraries
command as the API for this is chosen because introducing a new command
would introduce confusion due to multiple commands which differ only in
a subtle way.
This is both a short form of using a TARGET_DEFINED expression
together with a TARGET_PROPERTY definition, and a way to strip
non-target content from interface properties when exporting.
The test added by commit e378ba5f (Add CTestLimitDashJ test, 2012-12-26)
crashes with CTest compiled by Borland 5.8. There seems to be interaction
among the large number of internal ctest runs. It is probably related to
the undiscovered underlying issue mentioned in commit 32478069 (CTest:
Prevent creation of unbounded number of tests in ctest, 2012-12-18) when
fixing the symptom covered by the CTestLimitDashJ test.
Add --force-new-ctest-process to avoid the crash. Further investigation
will still be needed to identify the true problem.
Use a trailing slash to reference a directory. Require that a list
of associated files be specified to select from within the directory.
One may simply use DATA{Dir/,REGEX:.*} to reference all files but
get a directory passed on the command line.
Refactor use of the ExternalData_SERIES_MATCH value to avoid assuming
that it has no ()-groups that interfere with group indexing.
Extend the Module.ExternalData test to cover this case.
Add a Module.ExternalData test to verify data retrieval and test
argument DATA{} references.
Add a RunCMake.ExternalData test to verify error handling and automatic
transformation of a raw data to a content link and staged object.
7bf490e Make subclasses responsible for joining content.
f6b16d4 Don't allow targets args in the new target commands.
b3a7e19 Make the Property name protected so that subclasses can use it.
We need to make sure we can export targets which have content such
as $<0:$<TARGET_PROPERTY:not_a_target,INTERFACE_INCLUDE_DIRECTORIES>
That means making not finding a target non-fatal here.
These interface-related link-libraries properties are used to determine
the value of the other INTERFACE properties, so we were getting infinite
recursion and segfaults otherwise.
6063fef Output include directories as LOG messages, not warnings.
aa66748 Specify the target whose includes are being listed.
d70204a Only output includes once after the start of 'generate-time' when debugging.
0d46e9a Store includes from the same include_directories call together.
830246e Export the COMPATIBLE_INTERFACE_BOOL content properties
bd82bb4 Clear the link information in ClearLinkMaps.
e987991 Make INTERFACE determined properties readable in generator expressions.
d9afacc Exit early if we find an inconsistent property.
1800f70 Populate the link information cache before checking dependent properties.
With similar reasoning to the parent commit, as downstreams, we can't
determine what $<CONFIG> generator expressions would be appropriate.
Upstream would have populated the INTERFACE_INCLUDE_DIRECTORIES with
config-specific generator expressions, possibly appropriate for
their DEBUG_CONFIGURATIONS. In theory, if we would add include
directories for a DEBUG intent, we would have to match the upstream
configurations for that.
Rather than attempting to discover the appropriate configurations
at this time, simplify the feature instead. The use of IMPORTED targets
with these commands could still be added in the future if targets
would export their DEBUG_CONFIGURATIONS somehow.
This reverts commit 9cfe4f1b76.
It turns out that correctly adding the content to
the IMPORTED_LINK_INTERFACE_LIBARIES_<CONFIG> of an upstream target
from the buildsystem of a downstream project is not simple.
If upstream had added the INTERFACE content, the config-specific
properties would be determined by the DEBUG_CONFIGURATIONS of
upstream.
As downstream, we don't have any information about what
the DEBUG_CONFIGURATIONS of upstream were, so we can't determine
which configuration-specific properties to populate. The best we can do
is add it to all of them or add it to the ones downstream considers to
be DEBUG_CONFIGURATIONS, neither of which is a good solution.
So, removing the porcelain API for that is the best approach. A human
can still determine which properties to populate and use
the set_property API to populate the desired properies.
Another solution to this would be for upstream targets to publish
what they consider DEBUG_CONFIGURATIONS, but that can be added in
a future release.
Otherwise, we get a separate IncludeDirectoriesEntry for each include,
and that causes unnecessary and confusing splitting in the output when
debugging the INCLUDE_DIRECTORIES property.
This new expression allows checking how a policy was set when a target
was created. That information is only recorded for a subset of policies,
so a whitelist is used.
Set CMAKE_SUPPRESS_REGENERATION in the Lib1 and Lib2 projects so that
their .vcxproj files do not contain references to ZERO_CHECK. Such
references do not make sense when using the files in another .sln file.
This does not reduce the effectiveness of the test because real projects
that use include_external_msproject will have their own .vcxproj files not
generated by CMake anyway.
The ExternalProject_Add DEPENDS option adds two types of dependencies.
It adds a target-level build order dependency between the external
project target and the named targets. It also adds a file-level
dependency on the "done" stamp file of the named external project
targets. Targets not created by ExternalProject_Add have no such stamp
file and no _EP_STAMP_DIR property. Prior to commit d14c0243 (Refactor
repeated code into function, 2012-04-26) we unconditionally accepted an
empty stamp dir and generated a dependency on a non-existent file.
After that commit we generate an error that no stamp dir is set.
Skip the file-level dependency when the named dependency is not an
external project target in order to allow this use case. Teach the
ExternalProject test to cover the case.
1d74ba2 Test evaluation target via export for generator expressions
522bdac Export the INTERFACE_PIC property.
4ee872c Make the BUILD_INTERFACE of export()ed targets work.
1d47cd9 Add a test for the interfaces in targets exported from the build tree.
6c828f9 Move the exported check for file existence.
cfd4f0a Move the exported check for dependencies of targets
d8fe1fc Only generate one check per missing target.
f623d37 Don't write a comment in the export file without the code.
b279f2b Strip consecutive semicolons when preprocessing genex strings.
The Config and IMPORTED_ variants may also contain generator
expressions.
If 'the implementation is the interface', then the result of
evaluating the expressions at generate time is used to populate
the IMPORTED_LINK_INTERFACE_LIBRARIES property.
1) In the case of non-static libraries, this is fine because the
user still has the option to populate the LINK_INTERFACE_LIBRARIES
with generator expressions if that is what is wanted.
2) In the case of static libraries, this prevents a footgun,
enforcing that the interface and the implementation are really
the same.
Otherwise, the LINK_LIBRARIES could contain a generator
expression which is evaluated with a different context at build
time, and when used as an imported target. That would mean that the
result of evaluating the INTERFACE_LINK_LIBRARIES property for
a static library would not necessarily be the 'link implementation'.
For example:
add_library(libone STATIC libone.cpp)
add_library(libtwo STATIC libtwo.cpp)
add_library(libthree STATIC libthree.cpp)
target_link_libraries(libtwo
$<$<STREQUAL:$<TARGET_PROPERTY:TYPE>,STATIC_LIBRARY>:libone>)
target_link_libraries(libthree libtwo)
If the LINK_LIBRARIES content was simply copied to the
IMPORTED_LINK_INTERFACE_LIBRARIES, then libthree links to libone, but
executables linking to libthree will not link to libone.
3) As the 'implementation is the interface' concept is to be
deprecated in the future anyway, this should be fine.
Make a C executable instead of attempting to make a C++ static
library (and not really succeeding). This was introduced in
commit 894f52f3 (Handle INTERFACE properties transitively for
includes and defines., 2012-09-23).
3581b96 Process the INTERFACE_PIC property from linked dependencies
042ecf0 Add API to calculate link-interface-dependent bool properties or error.
bf5ece5 Keep track of properties used to determine linker libraries.
This allows a dependee to inform a target that it should have its
POSITION_INDEPENDENT_CODE property set to ON, or OFF. The value of
the POSITION_INDEPENDENT_CODE property, if set, must be consistent
with any INTERFACE_POSITION_INDEPENDENT_CODE properties on dependees.
Add a test covering the consistency checks on platforms where they run.
This makes
set(CMAKE_BUILD_INTERFACE_INCLUDES ON)
add the equivalent of
set_property(TARGET tgt APPEND PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
$<BUILD_INTERFACE:${CMAKE_CURRENT_SOURCE_DIR};${CMAKE_CURRENT_BINARY_DIR}>
)
to every target.
If the headers are in CMAKE_CURRENT_SOURCE_DIR, and the generated headers
are in CMAKE_CURRENT_BINARY_DIR, this is a convenient way to build a target
bar, which depends on foo, just by using target_link_libraries() and adding
the INTERFACE_INCLUDE_DIRECTORIES to the INCLUDE_DIRECTORIES of the target
being linked. There will be more-convenient porcelain API to consume the
property in the future.
This makes it possible to use:
target_link_libraries(foo LINK_INTERFACE_LIBRARIES bar)
where foo is an IMPORTED target. Other tll() signatures are not
allowed.
Previously we kept direct link dependencies in OriginalLinkLibraries.
The property exposes the information in the CMake language through the
get/set_property commands. We preserve the OriginalLinkLibraries value
internally to support old APIs like that for CMP0003's OLD behavior, but
the property is now authoritative. This follows up from commit d5cf644a
(Split link information processing into two steps, 2012-11-01).
This will be used later to populate the link interface properties when
exporting targets, and will later allow use of generator expressions
when linking to libraries with target_link_libraries.
Also make targets depend on the (config-specific) union of dependencies.
CMake now allows linking to dependencies or not depending on the config.
However, generated build systems are not all capable of processing
config-specific dependencies, so the targets depend on the union of
dependencies for all configs.
cc676c3 OS X: Detect implicit linker framework search paths
2dd67c7 OS X: Detect implicit link directories on modern toolchains
ba58d0c OS X: Link with all framework search paths, not just the last
894f52f Handle INTERFACE properties transitively for includes and defines.
f5b1980 Populate the ExportedTargets member early in GenerateMainFile
c67b812 Make cycles in target properties ignored, not an error.
d0f950f Use mapped config properties to evaluate $<CONFIG>
26def17 Make all relevant targets available in the genex context.
0c657dc Add API to populate INTERFACE properties in exported targets.
e04f737 Add API to extract target names from a genex string.
b0c8f73 Add the TARGET_NAME generator expression.
77475fe Allow generator expressions to require literals.
b2f1700 GenEx: Add expressions to specify build- or install-only values
This means for example, that consumers can use:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES})
instead of also needing to specify all 'public' dependencies:
target_link_libraries(foo ${QT_QTGUI_LIBRARIES} ${QT_QTCORE_LIBRARIES} )
when using the IMPORTED targets. Also populate the
IMPORTED_LINK_DEPENDENT_LIBRARIES property so CMake can help the linker
find shared library dependencies.
This is for specifying INCLUDE_DIRECTORIES relevant to the build-location
or the install location for example:
set_property(TARGET foo PROPERTY
INTERFACE_INCLUDE_DIRECTORIES
"$<BUILD_INTERFACE:${CMAKE_CURRENT_BINARY_DIR};${CMAKE_CURRENT_SOURCE_DIR}>"
"$<INSTALL_INTERFACE:${CMAKE_INSTALL_PREFIX}/include>"
)
A 'bar' target can then use:
set_property(TARGET bar PROPERTY
INCLUDE_DIRECTORIES
"$<TARGET_PROPERTY:foo,INTERFACE_INCLUDE_DIRECTORIES>"
)
and it will work whether foo is in the same project, or an imported target
from an installation location, or an imported target from a build location
generated by the export() command.
Because the generator expressions are only evaluated at build-time, these
new expressions are equivalent to the ZeroNode and OneNode.
The GeneratorExpression test is split into parts. Some shells can't run
the custom command as it is getting too long.
0941d62 Add a way to print the origins of used include directories.
18a3195 Keep track of INCLUDE_DIRECTORIES as a vector of structs.
76ea420 Use cmsys::auto_ptr to manage cmCompiledGeneratorExpressions
Resolve this warning:
".../Tests/CMakeCommands/target_link_libraries/depB.cpp", line 8: warning:
variable "a" was declared but never referenced
DepA a;
^
Stephen Kelly
Brad King
Rolf Eike Beer
Yury G. Kudryashov