e0e75a72 Help: Add notes for topic 'ctest-memcheck-sanitizers'
7345a1f7 tests: Add a test for ctest_memcheck MemorySanitizer
0c6330da ctest_memcheck: Add support for MemorySanitizer msan
9ba8bf12 tests: add a test for ctest_memcheck UndefinedBehaviorSanitizer
816c100a ctest_memcheck: Add support for UndefinedBehaviorSanitizer ubsan
b67ef537 ctest_memcheck: Order sanitizer type code consistently
f48a2968 Tests: Organize CTestTestMemcheck inner test code
Revert commit 7243c951 (Ninja: Don't limit custom cmd side-effects to
build folder, 2014-06-27) because it causes every custom command
dependency in the source tree to get a phony rule. For large projects
these rules get too big for Ninja to handle efficiently. While the
original change addressed a valid concern, it did not seem to occur
regularly in practice because well-behaved projects generate their
side-effects only in the build tree. Until we support explicit
specification of side-effects (CMake issue #14963), we will have to use
this as a middle-ground.
f25e431d tests: set sanitizer options properly
f0661bf3 tests: fix copy/paste from tsan -> asan comments
ca9cc25c ctest: add support for additional sanitizer options
0b9ffffc ctest: update documentation for CTEST_MEMORYCHECK_TYPE
When the file is not found in $CMAKE_SOURCE_DIR/<file path>,
the CurFileName pointer remained set to the previous file. This
caused the new file's coverage data to populate the into the
wrong object giving incorrect results and occasionally resulting
in a seg fault.
The pre-defined 'console' pool is a non-buffered pool that runs with a
depth of 1. CMake re-run cannot be run concurrently and it will
eventually output something. A non-buffered pool allows to get it as
soon as possible
Also, generate the minimal required version of Ninja in the build file.
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.
This version of the Intel Fortran plugin to Visual Studio says:
please make sure that $(OutDir), $(TargetName) and $(TargetExt)
property values match the value specified in %(Link.OutputFile)
We must set TargetName and TargetExt in addition to the existing
setting for OutputDirectory. The settings do not appear to hurt
older versions of Intel Fortran, so set them unconditionally.
Extend the FortranOnly test to cover a corresponding use case by
using the OUTPUT_NAME target property.
Inspired-by: Ian Harvey <Ian.Harvey@megms.com.au>
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
Also add a 'CMAKE_ANDROID_GUI' variable to set the property default
so a project can easily make all executables Android applications.
An Android application executable file has the same extension as a
shared library (.so).
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 'Android', check for an installation of
'NVIDIA Nsight Tegra Visual Studio Edition' and generate .vcxproj
files for the "Tegra-Android" platform. Also make the installed
version available in a CMAKE_VS_NsightTegra_VERSION variable.
In commit v3.0.0-rc1~429^2~2 (Remove the Location member from cmTarget,
2012-10-07) a few extra slashes were added to the path construction
logic, perhaps due to a partially implemented attempt at handling the
case that GetDirectory returns an empty string. This leads to LOCATION
paths with double slashes in some cases. Remove them now.
Unlike with Unix Makefiles generator modifying compiler paths was not
protected with Ninja generator. It was possible to modify them in the
cache without the expected effect on the generated solution. Also
activate corresponding tests with Ninja.
In cmGlobalGenerator::EnableLanguage, fix error messages for missing
module files to actually name the missing module instead of using the
empty string returned by GetModulesFile.
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.
be6a555d Tests: Test setting a generator platform in a toolchain file
d506fee8 Tests: Use -A option to pass generator platform selection
11c9ddd6 ExternalProject: Use -A option to pass generator platform
29bd843e CTest: Use -A option to pass generator platform selection
eb7d8156 cmake: Add -A option to specify a generator platform
858d5a0b Fix if() checks of CMAKE_SYSTEM_NAME on Cygwin
e177e7af FPHSA: Avoid if() dereferencing of quoted variable
425acc52 cmcurl: Use if(DEFINED) to simplify conditions
cede5cbd libarchive: Avoid depending on if() to dereference a quoted variable
2d97178b FindGTK2: Avoid depending on if() to dereference a quoted variable
0b12815d Modules/Test*.cmake: Use if(DEFINED) to simplify conditions
188a1f23 If: Introduce policy CMP0054 - don't dereference quoted variables in if()
b900c1cc If: Extract cmConditionEvaluator from if() implementation
Define the 'cmake -A' option to set CMAKE_GENERATOR_PLATFORM
without having to spell out the whole variable name. We choose
the name '-A' for "platform" because '-P' is already taken, and
in the common use case the "platform" is actually an architecture
(e.g. x64).
Teach the RunCMake test infrastructure to use -A to pass the generator
platform. Extend the RunCMake.GeneratorPlatform test with a case to
verify that the -A option cannot be repeated.
The CMAKE_SYSTEM_NAME is "CYGWIN", but we also define a variable
named "CYGWIN" to "1". Avoid allowing if() to expand the "CYGWIN"
string as a variable.
Call SetSystemName, SetGeneratorPlatform, and SetGeneratorToolset
exactly once after reading CMakeSystem.cmake, and not again on another
call to enable_language() or project().
On Arch Linux, /lib and /lib64 are symlinks to /usr/lib. When ordering
runtime library search paths, we must not consider these to be distinct
directories. Before considering conflicts between two directories,
check that they do not have the same 'realpath'.
Inspired-by: Myles English <mylesenglish@gmail.com>
The ctest_configure command already reads the CTEST_CMAKE_GENERATOR
variable to get the value for the cmake -G option. Read new variable
CTEST_CMAKE_GENERATOR_PLATFORM to pass on as CMAKE_GENERATOR_PLATFORM.
The "ctest --build-and-test" mode already has "--build-generator" to
specify the -G option to CMake. Add a "--build-generator-platform" option
to specify a value to pass on as CMAKE_GENERATOR_PLATFORM.
For VS generator names that do not specify the platform name, read
CMAKE_GENERATOR_PLATFORM to get it.
Extend the RunCMake.GeneratorPlatform test with a case covering
use of the x64 platform when the test generator is a Visual Studio
generator whose name does not specify a platform.
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_PLATFORM and associated variable documentation to
hold the value persistently.
Add a RunCMake.GeneratorPlatform test to cover basic use cases for the
option. Verify that CMAKE_GENERATOR_PLATFORM is empty by default, and
that it is rejected when the generator does not support a user setting.
Rename the 'PlatformName' member to 'DefaultPlatformName' and make
sure it is only read through a 'GetPlatformName()' call. This will
allow non-default names to be chosen later.
Move handling of an empty toolset name into the implementation of the
method. This simplifies the VS 10 implementation of default toolset
selection because it has one code path that is always called.
Xcode requires a separate PBXFileReference for each target source group
that references a source file. Xcode 6 now diagnoses re-use of the same
PBXFileReference from multiple source groups. Add the referencing
target name to our internal map key so we use a per-target reference.
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).
Move the member from cmGlobalVisualStudio10Generator to
cmGlobalVisualStudio7Generator to make it useful for earlier
versions of VS. Set the member to true only starting with
cmGlobalVisualStudio8Generator since we will not implement
MASM support for versions less than VS 8.
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
aa21001b Help: Add notes for topic 'vs-special-source-file-properties'
6fe770e1 VS: Add a source file property to set the hlsl shader type
9b4dc2ad VS: Add a source file property to mark content for Windows App deployment
f063a914 VS: Re-arrange WriteExtraSource to support tool configuration
653529ce CTest: Allow / to be in the build name, and be consistent with the build name
39b5df2f ctest_update: Add CTEST_UPDATE_VERSION_ONLY option to only note the version
Prior to this change / was not allowed in the build name. This was tested
with a CDash server and worked. In addition the safe build name was not
used everywhere. This caused mismatched build names to be in the xml
files going to CDash which caused different rows to be created for the
same build.
This allows ctest_update to get the current version without actually
changing the repository. This is useful when using Jenkins or an
external project to update the source to a specific version, but you
still want the current version to show up in CDash.
The lexer changes in commit v3.0.0-rc1~495^2 (Add Lua-style long
brackets and long comments to CMake language, 2013-08-06) accidentally
left out matching '[' as a single character in an unquoted argument.
Add a lexer rule to match it and extend the RunCMake.Syntax test to
cover this case.
The current file parser for a MUMPS routine uses a period "." as the
one of the signals that a line of MUMPS code is executable. This is not
a correct assumption. Add the period to the list of characters that CTest
will not consider the start of a line of code.
Update the test routine to have an entry point with code to match the scenario
mentioned above.
Run cmparseMSBuildXML.py on masm.xml to generate our flag tables:
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/BuildCustomizations/masm.xml" > cmVS10MASMFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V110/BuildCustomizations/masm.xml" > cmVS11MASMFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V120/BuildCustomizations/masm.xml" > cmVS12MASMFlagTable.h
python cmparseMSBuildXML.py -x ".../MSBuild/Microsoft.Cpp/v4.0/V140/BuildCustomizations/masm.xml" > cmVS14MASMFlagTable.h
Fix up the declaration names at the top of each file.
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.
CPack IFW generator updates:
- Group now can have script;
- Root package (for monolithic or one package installers) can be
configured from group.
CMake updates:
- Native installation (no Unspecified component).
Teach the Makefile generators to escape '#' characters on the right hand
side of variable assignments in flags.make. This is needed for flags
like '-Wno-error=#warnings'. Otherwise the make tool treats them as
comments and leaves them out of the _FLAGS variable value.
Add a case to the CompileOptions test covering '#' in a COMPILE_OPTIONS
value, at least on compilers where it is known to be supported.
2b20110f MSVC: Select default standard libraries for ARM platform
2dfcf0ed VS: Fix generation of desktop applications for ARM
dbb5a7ee CMakeDetermineCompilerId: Fix detection for VS ARM platform
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.
5d3d9a22 Help: Add notes for topic 'vs-windows-phone-and-store'
401a00d9 VS: Set WindowsPhone and WindowsStore min VS version required
709cebde VS: Generate WindowsPhone and WindowsStore application types
72395ab2 VS: Add .sln "Deploy" mark for WindowsPhone and WindowsStore binaries
2074f581 MSVC: Add system libs for WindowsPhone and WindowsStore
c72f0887 MSVC: Add default WindowsPhone and WindowsStore compile flags
1c94558a MSVC: Disable incremental linking for WindowsPhone and WindowsStore
592098e2 Define 'WINDOWS_PHONE' and 'WINDOWS_STORE' variables
aa42a78f Add WindowsPhone and WindowsStore platform information modules
b94ddf6c CMakeDetermineCompilerId: Recognize WindowsPhone and WindowsStore
d7938bff VS: Select WindowsPhone and WindowsStore default toolsets
3abd150c VS: Save WindowsPhone and WindowsStore system internally
Split the monolithic cmCPackIFWGenerator source into three parts:
cmCPackIFWGenerator, cmCPackIFWInstaller, and cmCPackIFWPackage
to isolate the implementations somewhat.
Add a COMMON option to the cpack_ifw_configure_component command to make
the data component common to its parent group.
Change the default packaging method to ONE_PACKAGE_PER_COMPONENT.
This is not incompatible because the CPack IFW generator has not
yet been in a release.
The implementation of CMP0047 detects the QNX compiler id internally,
then changes it to GNU after the language is fully enabled. This is too
late to correctly set the old IS_GNU variables, so set them as part of
the policy OLD behavior.
Reported-by: Mike Lattanzio <mlattanzio@blackberry.com>
When $<TARGET_PROPERTY> names a build property like COMPILE_DEFINITIONS
but not the usage requirement (INTERFACE_) version of it, the value
should be that used to build the target. It should not be influenced by
a dependent 'head' target like usage requirements are.
Extend the CompileDefinitions test with a case covering the corrected
behavior.
Reviewed-by: Stephen Kelly <steveire@gmail.com>
The context->Makefile is never NULL, but our checks for it convince
Clang scan-build that it might be NULL. Then it warns about later
unchecked uses. Drop the unnecessary checks.
This showed up because scan-build noticed outputFull was basically
a constant. Logic should be output all valgrind output. Then output
regular test output until output limit is reached.
Teach the VS >= 10 generators to recognize these system names and select
the appropriate default toolset for the system version. Report an error
when the version is not known to be supported by VS.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
Add boolean members to the VS >= 10 global generator to save
whether CMAKE_SYSTEM_NAME is WindowsPhone or WindowsStore
without having to repeat a string comparison.
Inspired-by: Gilles Khouzam <gillesk@microsoft.com>
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.
No call sites pass NULL to the output argument, so take it by
reference to avoid the if(output) conditions. Propagate the
change through the TryCompile APIs that call it.
After calls to ProcessSourceItemCMP0049, check for an empty return
string to detect a failure instead of trusting GetErrorOccuredFlag.
The latter could have been left from a preceding non-fatal error.
Extend the RunCMake.Configure test to cover a case that exposed this
problem.
Add a new additional entry to the FilePaths array when a
"package" tag has been found. This path should consist of the package
information found appended to the projects source directory.
This change will allow code held in a /src/main/java/* directory off of the
projects source directory to be found, unlike now which assumes a subdirectory
contains the code.
The linker will bring in shared libraries as a whole and use them even
for symbols that are needed by entries later in the link line.
Therefore we do not need to repeat them. De-duplicate link entries that
we know are shared libraries because we have a cmTarget associated with
them.
Tested-by: Jean-Christophe Fillion-Robin <jchris.fillionr@kitware.com>
0ac28adc VS: Map .jpg and .png sources to Image tool
58bb14d4 VS: Map .xml to XML tool
972cf1d7 VS: Map .appxmanifest sources to AppxManifest tool
15fb1022 VS: Refactor handling of resx headers
c2ef6d23 VS: Refactor handling of "header" sources in VS >= 10
2df38911 VS: Refactor handling of "extra" sources in VS >= 10
143b4005 VS: Convert 'WriteSource' tool argument to std::string
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.
Add a virtual cmGlobalVisualStudio10Generator::InitializeSystem method
called from SetSystemName once the SystemName and SystemVersion members
have been populated. This will give VS version-specific generators a
chance to recognize and adapt to the target system.
Xcode 6 introduced an 'OTHER_LIBTOOLFLAGS' setting for the "Other
Librarian Flags" of a static library. Now 'OTHER_LDFLAGS' are ignored.
Teach the Xcode generator to choose the correct name for the build
setting based on the type of target and the version of Xcode.
Inspired-by: Jamie Kirkpatrick <jkp@spotify.com>
b9be4d21 Help: Add notes for topic 'cpack-ifw-generator'
73b336c9 CPackIFW: Replace use of strftime with cmTimestamp
44850a26 CPack: Add an "IFW" generator for Qt Framework Installer
09164c63 VS: Encode more content correctly in vcxproj files (#15031)
29a0642b VS: Encode mapped flag values in XML project files (#15031)
8fa087ab cmVisualStudioGeneratorOptions: Simplify XML escaping API
1c209ac1 cmIDEOption: Store mapped flag values as a vector<string>
91c93354 cmVisualStudio10TargetGenerator: Remove dupilcate line
The cmGlobalGenerator::ResolveLanguageCompiler method, invoked only by
Makefile generators, contains code originally added by commit v2.4.0~796
(..., add new generators for msys and mingw, 2005-12-22) to compute the
full path to the compiler and save the result back into the cache value.
Since then the CMakeDetermine*Compiler modules have learned to resolve
the full path to the compiler and save it in CMake*Compiler.cmake files
configured in the build tree. The value of CMAKE_<LANG>_COMPILER in the
cache is now only for reference of what the user originally specified.
The full path is now available in a normal variable of the same name,
and this is used by project code and the generators.
When the user specifies -DCMAKE_<LANG>_COMPILER=name on the command-line
of an existing build tree that uses a Makefile generator, it is first
stored in the cache with an uninitialized type. Then later when
ResolveLanguageCompiler updates the cache entry and sets the type to
FILEPATH, cmMakefile::AddCacheDefinition does CollapseFullPath on the
"name" and ends up with something like "$PWD/name" which is unlikely to
be correct. Furthermore, cmMakefile::AddCacheDefinition proceeds to
remove the normal variable of the same name, so the value originally
saved in CMake<LANG>Compiler.cmake is ignored and the generators use the
wrong path to the compiler.
Resolve this by dropping the code from ResolveLanguageCompiler that
touches the cache value of CMAKE_<LANG>_COMPILER. As explained above it
is no longer needed anyway.
Since the Sanitizers write out one log file per process, a single
test might have more than one log file. This commit allows ctest
to read all of the log files found for a particual test.
In cmVisualStudio10TargetGenerator, add missing cmVS10EscapeXML
calls around paths to source and object files, custom command
dependencies and outputs, and platform name/version values.
Teach cmVisualStudioGeneratorOptions to encode FlagMap entries
and the FlagString value properly in vcproj/vcxproj XML files.
Update the one existing call site that pre-encoded the value
to not do so.
Brad King
Kitware Robot
Bill Hoffman
Ben Boeckel
Nils Gladitz
Konstantin Podsvirov
Clinton Stimpson
Jonathan Beezley
Sylvain Joubert
Pascal Bach
Gilles Khouzam
Stephen Kelly
Joseph Snyder
Daniel Pfeifer