df84281d Help: Add notes for topic 'vs-nsight-tegra-generator'
69e198dc VS: Generate Nsight Tegra project revision number
5365c9ac VS: Map Nsight Tegra file types in .vcxproj files
178f56a5 VS: Fix Tegra-Android platform linking of libraries by name
7115702f Tests: Add test for VS Nsight Tegra generator support
a6289499 VS: Generate ANDROID_GUI executables as app packages
c12e4699 Add 'ANDROID_API' target property to set Android Target API
9a4df52a Add 'ANDROID_GUI' target property to mark Android applications
16569abf cmTarget: Track internally whether platform is Android
ef0fd4f0 VS: Teach vcxproj generation about the Tegra-Android platform
d09b60f5 VS: Detect compiler id of Nsight Tegra-Android toolchains
2f071466 VS: Teach VS >= 10 to recognize CMAKE_SYSTEM_NAME 'Android'
Nsight Tegra 2.0 will be revision '8'. Generate this revision number
and add a NsightTegraUpgradeOnceWithoutPrompt element to tell newer
versions not to prompt when upgrading the generated project file.
Map ".java" to JCompile, ".asm" and ".s" to ClCompile, and a few
Android-specific source file names to AndroidBuild. This allows
Nsight Tegra 1.6 and above to check up-to-dateness of such sources.
Bump NsightTegraProjectRevisionNumber to 7 to allow these fields.
When an executable is marked with ANDROID_GUI, generate an AntBuild
step in the .vcxproj file and point it at the directory found to
contain AndroidManifest.xml. Assume it also contains build.xml.
c655f0c4 VS: Drop GenerateManifest from .vcxproj files for non-MS tools
227a3367 VS: Use case-insensitive check for hlsl,jpg,png,xml file extensions
4a24015a Tests: Always detect VS and SDK availability on Windows
Complete the basic implementation of the VS Tegra-Android generators
by replacing parts of vcxproj files that are specific to MS tools
with settings defined for the NVIDIA Nsight Tegra tools.
Current limitations include:
* We have no "flag table" so flags will be passed in the additional
options fields instead of mapped to the vcxproj elements defined
by Nsight Tegra msbuild platform definition files.
* We have no interface to set the AndroidArch, AndroidStlType, or
AndroidTargetAPI fields so defaults will be used.
* The Nsight Tegra msbuild platform definition files do not provide
a working "Utility" target type so for add_custom_target we need
to use a "StaticLibrary" target type and leave out ClCompile rules.
* There is also no target type for plain command-line executables
so for add_executable we need to use a "DynamicLibrary" target.
Full application bundles will likely require new CMake target
properties (like WIN32_EXECUTABLE for Windows GUI executables).
When CMAKE_SYSTEM_NAME is 'WindowsCE':
* Set the Subsystem and EntryPointSymbol accordingly.
* When CMAKE_SYSTEM_VERSION is 8.0 (Windows CE 2013),
select the CE800 toolset by default.
39fefde2 VS: Add test case for Windows Phone and Windows Store
89da8465 MSVC: Define 'WIN32' for Windows Store and Windows Phone
ed7f085f Help: Add notes for topic 'vs-windows-apps'
dd11ae8f VS: Do not compile C sources as WinRT (#15100)
b8e40538 VS: Mark Windows Phone and Store targets as App Containers
0432f062 VS: Always ignore ole32 on Windows Phone 8.0
e6ff2f8b VS: Generate Windows Metadata for WinRT components
ee48f4c7 VS: Generate Windows Phone and Windows Store projects as Unicode
cb1aceed VS: Add VS_WINRT_COMPONENT property to enable CompileAsWinRT
401269e4 VS: Handle .pfx files explicitly in generator
23782171 VS: Handle AppxManifest sources explicitly in generator
bc373c6d VS: Set Window Phone/Store app type in CMake-generated targets
d89b2889 VS: Mark CMake-generated targets as Utility in .vcxproj files
03ad8f28 CMakeDetermineCompilerABI: Link with standard libraries on MSVC
The MSVC /ZW flag is valid only for C++ sources. Whenever we enable
CompileAsWinRT for the whole target, disable it for all C sources.
Update the documentation of VS_WINRT_COMPONENT to drop the statement
about undefined behavior for non-C++ sources, because it is now
defined as expected.
* Add AppContainerApplication to non-UTILITY targets
* Generate app manifest and related files if project does not provide them.
Place them in a per-target directory to avoid clashes.
* Mark WinRT components with WinMDAssembly
* Import Windows Phone 8.0 targets in .vcxproj files when necessary,
and reference platform.winmd.
Inspired-by: Paul Annetts <paul@lightunobscured.com>
cbd1d42b Help: Add notes for topic 'vs-masm'
0f8522a6 VS: Add MASM support to VS 8 and 9 (#8170, #14984)
a43f4400 VS: Move internal MasmEnabled member up to VS 7 generator
df3b007d VS: Add test for MASM support
e8727449 VS: Populate MASM tool build settings in .vcxproj files
0271a5f9 VS: Manually fix MASM flag table entries
1d662e48 VS: Generate MASM flag tables from MSBuild tool files
4f6940df VS: Fix ASM_MASM support in VS >= 10
d7866c52 ASM_MASM: Fix selection of ml64
0374abdb ASM_MASM: Add preprocessor definitions to compile lines
5b0a46e1 ASM_MASM: Do not require compiler to be a full path
802dbe52 cmLocalVisualStudio7Generator: Rename local 'lang' var
Deprecate VS_WINRT_EXTENSIONS and document VS_WINRT_COMPONENT as for VS
generators only. Also define _WINRT_DLL in SHARED libraries in order to
get a .lib produced.
Inspired-by: Paul Annetts <paul@lightunobscured.com>
Teach cmGeneratorTarget to classify .pfx files as package
certificate key files. Teach cmVisualStudio10TargetGenerator
to write them as PackageCertificateKeyFile in .vcxproj files.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
Teach cmGeneratorTarget to extract .appxmanifest sources separately.
Teach cmVisualStudio10TargetGenerator to write them with the
AppxManifest tool in .vcxproj files. This will allow us to detect
whether the project provides an application manfiest explicitly.
Generate the ApplicationType and ApplicationTypeRevision elements in
.vcxproj files for CMake-generated targets like 'INSTALL' and
'RUN_TESTS'. This was accidentally left out of commit 709cebde (VS:
Generate WindowsPhone and WindowsStore application types, 2014-07-31).
5fcb42ab VS: Refactor include directory generation in .vcxproj files
8e026aa7 VS: Refactor include directory slash conversion
9633d112 cmIDEOptions: Add HasFlag method to test if a flag is set
84100102 cmIDEOptions: Add an AppendFlag overload to append multiple values
Use the cmVisualStudioGeneratorOptions flag map to add the
AdditionalIncludeDirectories element to the project file.
Move appending of %(AdditionalIncludeDirectories) to the
locations that populate the flag vectors instead of where
they are written out.
Create a VS_DEPLOYMENT_CONTENT source file property, supporting
generator expressions, to compute whether a source file should be marked
as DeploymentContent or ExcludedFromBuild in Windows Phone and Windows
Store projects.
Inspired-by: Minmin Gong <minmin.gong@gmail.com>
Add WindowsSDKDesktopARMSupport to the .vcxproj to avoid 'error MSB8022:
Compiling Desktop applications for the ARM platform is not supported.'
from VS.
Append %(IgnoreSpecificDefaultLibraries) to any user-specified
libraries so that the system-default list of libraries to ignore
is honored even when the user specifies more.
Create a WriteHeaderSource method to handle writing of sources
classified by cmGeneratorTarget as header files. This will be
useful to add special VS-specific handling for some headers.
Create a WriteExtraSource method to handle writing of sources not
classified by cmGeneratorTarget for any particular purpose. This
will be useful to add special VS-specific handling for some sources.
In cmVisualStudio10TargetGenerator, add missing cmVS10EscapeXML
calls around paths to source and object files, custom command
dependencies and outputs, and platform name/version values.
Some FlagMap entries are ;-lists. Store values as vector<string> so
that individual values may contain ';' characters. Delay the
construction of the final ;-list until writing to the VS project file.
With this approach the generated file may contain ;-separated values
that contain encoded ';' characters.
Make blocks adding MS-tool-specific options conditional on a
new "MSTools" boolean member of cmVisualStudio10TargetGenerator.
Hard-code the member to true for now to preserve existing behavior.
Teach the VS >= 10 generator to honor flags other than -I and -D
in the CMAKE_RC_FLAGS[_<CONFIG>] variable. Place them within the
ResourceCompile .vcxproj element under AdditionalOptions.
Also add a rudimentary flag map to map '-n' to 'NullTerminateStrings'.
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/V140/1033/cl.xml" > cmVS14CLFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/lib.xml" > cmVS14LibFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/1033/link.xml" > cmVS14LinkFlagTable.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.
Co-Author: Pawel Stopinski <diokhan@go2.pl>
Factor a WriteMSToolConfigurationValues helper method out of the
cmVisualStudio10TargetGenerator::WriteProjectConfigurationValues method
to isolate the configuration settings specific to MS tools.
The cmVisualStudio10TargetGenerator::ComputeClOptions method is
only called when the target type compiles, so do not duplicate
that check in the implementation.
When a binary output file is to have no extension, the TargetExt
element in the vcxproj cannot be left empty because VS will choose
a default extension. Instead use "." because the Windows filesystem
will treat that as an empty extension.
In cmVisualStudio10TargetGenerator, convert the static functions
currently used to lookup the flag table for each tool into class
methods. This avoids passing the this->LocalGenerator member and
gives the methods access to other information that may be useful
in the future.
As explained in cmVisualStudio10TargetGenerator::WriteSource comments,
VS tools append relative paths to the current directory, e.g.
c:\path\to\current\dir\..\..\..\relative\path\to\source.c
and fail if this is over 250 charaters or so. Previously we used a full
path only if no relative path could be constructed with a leading "../"
sequence that does not escape the source or build tree. This means that
long relative paths can be generated when the build tree is inside the
source tree, and can cause build failures due to the above path
concatenation problem.
Teach cmVisualStudio10TargetGenerator::ConvertPath to ask the Convert
method to honor CMAKE_USE_RELATIVE_PATHS. This will cause it to use
full paths by default but still give users the option of getting the
relative paths when possible.
Suggested-by: Josh Green <inbilla@gmail.com>
Disallow the use of config-specific source files with
the Visual Studio and Xcode generators. They don't have
any way to represent the condition currently.
Use the same common-config API in cmQtAutoGenerators. While
it accepts config-specific files, it doesn't have to support
multiple configurations yet.
Loop over the configs in cmTargetTraceDependencies
and cmGlobalGenerator::WriteSummary and consume all source
files.
Loop over the configs in cmComputeTargetDepends and compute the
object library dependencies for each config.
Remove use of UseObjectLibraries from Makefile and Ninja generators. It
is not needed now because those generators use GetExternalObjects
which already contains the objects from object libraries.
The VS10 generator calls both the UseObjectLibraries and the GetExternalObjects
methods. Ensure that duplicates are not created by skipping objects
from object libraries in handling of GetExternalObjects.
Similarly, fix VS6, VS7 and Xcode object handling by skipping
external objects from OBJECT_LIBRARY usage as appropriate.
The error message in the BadSourceExpression1 test is now reported
by the generator expression evaluator, so it has different text.
Until now the cmCustomCommandGenerator was used only to compute the
command lines of a custom command. Generalize it to get the comment,
working directory, dependencies, and outputs of custom commands. Update
use in all generators to support this.
Since commit v2.8.12~437^2~2 (VS: Separate compiler and linker PDB files
2013-04-05) we no longer set /Fd with the PDB_NAME or PDB_OUTPUT_DIRECTORY
properties. Those properties now exclusively handle linker PDB files.
Since STATIC libraries do not link their compiler PDB file becomes more
important. Add new target properties "COMPILE_PDB_NAME[_<CONFIG>]" and
"COMPILE_PDB_OUTPUT_DIRECTORY[_<CONFIG>]" to specify the compiler PDB
file location and pass the value to the MSVC /Fd option.
In VS <= 9 we already convert include paths to use backslashes
but the conversion was left out of the VS >= 10 generator.
Add the conversion now for consistency. VS 11 and 12 now require
it because they mistakenly interpret forward-slash options that
happen to occur in paths:
http://connect.microsoft.com/VisualStudio/feedback/details/778367
As an INTERFACE_LIBRARY has no direct link dependencies, we can
short-circuit in cmGeneratorExpressionEvaluator and
in cmGlobalGenerator::CheckLocalGenerators.
As they do not generate any output directly, any generate- or install-
related code acn also be short-circuited. Many of the local generators
already do this.
Because only INTERFACE related properties make sense on INTERFACE_LIBRARY
targets, avoid setting other properties, for example via defaults.
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.
The MSBuild version for each Visual Studio generator isn't 4.0. With
Visual Studo 2013 the ToolsVersion moved from being tied to the .NET
framework and now has its own version number.
Fix generation of the AdditionalIncludeDirectories element content to
escape for XML syntax. We already escape content of other elements,
this one was simply missing by accident.
Use the WIN32_EXECUTABLE target property only to set the SubSystem build
attribute default. When user-specified flags are later parsed they may
then override it.
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)
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.
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.
Replace the cmLocalGenerator GetCompileOptions method with an
AddCompileOptions method since all call sites of the former simply
append the result to a flags string anyway.
Add a "lang" argument to AddCompileOptions and move the
CMAKE_<LANG>_FLAGS_REGEX filter into it. Move the call sites in each
generator to a location that has both the language and configuration
available. In the Makefile generator this also moves the flags from
build.make to flags.make where they belong.
Brad King
Pascal Bach
Gilles Khouzam
Martin Mitas
Stephen Kelly
Clinton Stimpson
Ben Boeckel
Robert Maynard
Patrick Gansterer
Jonas Andersen
Christian Maaser