Teach the Preprocess test to get, set, and then get the same value for
the COMPILE_DEFINITIONS target property and verify that the value is not
changed. This ensures the internal structured storage of the property
value can reproduce the original string value.
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.
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.
The line
set( ${basename}_LIBRARY )
removes the normal variable, but if the corresponding cached variable is
present then line
list( APPEND ${basename}_LIBRARY optimized "${_libname}" )
uses that and fails. Replace the original line with
set( ${basename}_LIBRARY "" )
to set the normal variable to empty instead of unsetting it.
In CMakeTestFortranCompiler we build a test program using a Fortran 90
construct to check whether the compiler supports the language. Some
compilers have options to require explicit variable types. Fix the test
program to use an explicit variable type so it passes under such a
configuration.
Suggested-by: Neil Carlson <neil.n.carlson@gmail.com>
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