Unlike other target properties, this does not have a corresponding
non-INTERFACE variant.
This allows propagation of system attribute on include directories
from link dependents.
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.
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
If the CTest make program is not msbuild we find the msbuild
corresponding to the current test generator. In the case of
VS 12 search for the msbuild it provides.
Run cmparseMSBuildXML.py on cl.xml, lib.xml, and link.xml to generate
our flag tables:
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/cl.xml" > cmVS12CLFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/lib.xml" > cmVS12LibFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/v120/1033/link.xml" > cmVS12LinkFlagTable.h
Fix up the declaration names at the top of each file. Finally, teach
cmVisualStudio10TargetGenerator to select the version of the table
matching the version of VS.
Copy cmGlobalVisualStudio11Generator to cmGlobalVisualStudio12Generator
and update version numbers accordingly. Add the VS12 enumeration value.
Add module CMakeVS12FindMake to find MSBuild. Look for MSBuild in its
now-dedicated Windows Registry entry. Teach the platform module
Windows-MSVC to set MSVC12 and document the variable. Teach module
InstallRequiredSystemLibraries to look for the VS 12 runtime libraries.
Teach tests CheckCompilerRelatedVariables, Preprocess, VSExternalInclude,
and RunCMake.GeneratorToolset to treat VS 12 as they do VS 10 and 11.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
In each .l and .y input file that has instructions for manual
transformation of the output to include a step to remove the 'register'
storage specifier.
This has been requested, along with a patch, by Shaun Williams
in http://public.kitware.com/Bug/view.php?id=13788 .
It adds a global property AUTOMOC_TARGETS_FOLDER, which can
be used to group the automoc targets together in a folder e.g.
in Visual Studio.
Alex
In my project group we are using CMake to generate c++/cli winform
projects and I noticed the work done in commit 79ec7868 (VS: Add Windows
Forms Support, 2013-04-29) was in the right direction for solving some
of the problems we were facing.
The changes as submitted was breaking some functionality in our
projects, so I made some changes that fixes our problems and I believe
that it will also work for others.
* Resx files did not link correctly with the winform h-file so I added
the Resx configuration to the vcxproj file.
* I removed the functionality for setting <CLRSupport> true for the
project based on if an resx-file is pressent. This is preventing
us from using native cpp code. Also this do not address that some
projects will need to set other options like clr:pure, clr:safe.
This could be implemented as a cmake option, so it is possible to
specify exactly what is needed. Existing VSWindowsFormsResx Test
project is updated so it will be working with my changes.
d221eac Refactor target COMPILE_OPTIONS and COMPILE_FLAGS handling
b6385ca Escape target flags taken from COMPILE_OPTIONS
0c9cc9a Embarcadero: Use response files only for includes, objects, and libs
