Use constructs similar to those for COMPILE_OPTIONS. This is a little
different because there is a command to remove_definitions(), so
we can't populate the equivalent target property until generate-time
in cmGlobalGenerator.
This reverts commit de4da665d3205afa239749c41513a315c3831f51.
This feature is not yet ready for release. It needs to be
merged with the CMAKE_OSX_SYSROOT feature.
Use preprocessor loops and add a unit test for the appropriate
policies. All policies whose value is recorded at target creation
time should be part of this list.
When CMake reports failure to configure a project, especially when the
toolchain does not initialize properly, the true reason may be clear
from reading the CMakeFiles/CMake(Output|Error).log files. Advise users
to look at these files if they exist when configuration fails.
Add RunCMake.Configure test to check that the log files are mentioned
when configuration fails.
We have two mappings for the "/MAP" flag. The first does not care
whether there is a value and activates the GenerateMapFile boolean
setting. The second takes a value and puts it in the MapFileName
setting. The latter must treat the ":" as part of the flag.
This is similar to commit 8ae66bf4 (Fix optionally-valued booleans in VS
10 flag table, 2009-10-23).
The wording "Commands in the file are processed immediately as if they
were written in place of the include command" sounds as if some kind of
macro replacement is performed. This is not accurate. Update the
wording to describe behavior of the included code in terms of the
variable access scope.
Always populate the INTERFACE_LINK_LIBRARIES for interface
entries. Don't populate the old interface properties
matching (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?
if CMP0022 is NEW.
Because the INTERFACE_LINK_LIBRARIES property is now populated by
the target_link_libraries when operating on a static library,
make an equivalent change which populates the property with
the same value when the old link_libraries() command is used. This
silences the policy warning in that case.
This property is generated only for targets which have recorded
policy CMP0022 as NEW, and a compatibility mode is added to
additionally export the old interfaces in that case too.
If the old interfaces are not exported, the generated export files
require CMake 2.8.12. Because the unit tests use a version which
is not yet called 2.8.12, temporarily require a lower version.
This property replaces the properties which
match (IMPORTED_)?LINK_INTERFACE_LIBRARIES(_<CONFIG>)?, and is enabled
for IMPORTED targets, and for non-IMPORTED targets only with a policy.
For static libraries, the INTERFACE_LINK_LIBRARIES property is
also used as the source of transitive usage requirements content.
Static libraries still require users to link to all entries in
their LINK_LIBRARIES, but usage requirements such as INCLUDE_DIRECTORIES
COMPILE_DEFINITIONS and COMPILE_OPTIONS can be restricted to only
certain interface libraries.
Because the INTERFACE_LINK_LIBRARIES property is populated unconditionally,
we need to compare the evaluated result of it with the link implementation
to determine whether to issue the policy warning for static libraries. For
shared libraries, the policy warning is issued if the contents of
the INTERFACE_LINK_LIBRARIES property differs from the contents of the
relevant config-specific old LINK_INTERFACE_LIBRARIES property.
CMake requires the top-level CMakeLists.txt to contain a direct call to
the project() command and will insert one if there is not. Document
this requirement since some authors have tried to use include() to load
a file calling the project command.
This was missing from commit 30962029 (Make targets depend on the
link interface of their dependees., 2012-12-26), which caused
only immeditate entries of the link interface to become target
depends.
Entries from the cmMakefile are processed and maintained similarly
to other include directories. The include_directories(SYSTEM)
signature affects all following targets, and all prior targets
in the same makefile.
Add to the brief documentation of the Visual Studio 10, 11, and 12
generators the corresponding VS product year. Clarify that VS11 is for
Visual Studio 2012, and VS12 is for Visual Studio 2013.
9a76d83 VS12: Find proper MSBuild for VSProjectInSubdir test
4e5cb39 Merge branch 'master' into vs12-generator
78fdbbc FindBoost: Add -vc120 mangling for VS 12
e99d7b1 VS12: Generate flag tables from MSBuild v120 tool files
77ac9b8 VS12: Add Visual Studio 12 generator (#14251)
539356f Ninja: Custom Command file depends don't need to exist before building
874e171 Ninja: GlobalNinjaGenerator WriteBuild and WritePhonyBuild non static
88d27ad Add a test to expose a bug with add_custom_command and ninja.
When converting custom commands for the ninja build system we
need to make sure that any file dependencies that exist in the build
tree are converted to phony targets. This tells ninja that these
files might not exist when starting the build, but could be generated
during the build.
This is done by tracking all dependencies for custom command targets.
After all have been written out we remove all items from the set
that have been seen as a target, custom command output, an alias,
or a file in the source directory. Anything that is left is considered
to be a file that will be generated as a side effect of another
custom command.
To properly track the usage of dependencies that are generated at
compile time as the side effect of other build steps we need
to make the WriteBuild and WritePhonyBuild commands non static
