Visual Studio 12 (2013) deprecated GetVersionEx:
warning C4996: 'GetVersionExW': was declared deprecated
in favor of either "versionhelpers.h" or VerifyVersionInfo, neither of
which exist in some of the older compilers we support. Rather than
try to port conditionally to VerifyVersionInfo, simply suppress the
warning for now.
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.
Call SetSystemName, SetGeneratorPlatform, and SetGeneratorToolset
exactly once after reading CMakeSystem.cmake, and not again on another
call to enable_language() or project().
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.
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.
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>
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.
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.
Make the virtual 'Generate' method protected. Make 'DoGenerate'
the main entry point to generation. This gives cmGlobalGenerator
a chance to do some early operations before the individual
generator-specific implementations take over.
Add a cmGlobalGenerator::SetSystemName virtual method. Call it from
cmGlobalGenerator::EnableLanguage as soon as CMAKE_SYSTEM_NAME is known.
This will give generators a chance to adapt themselves to the target
system. Pass the cmMakefile instance to the method so that the
generator can update it accordingly. Return early from EnableLanguage
if SetSystemName returns false.
Delay use of CMAKE_GENERATOR_TOOLSET until the CMakeSystem.cmake
file has been configured and loaded during the first project() or
enable_language() command. This gives the toolchain file named by
CMAKE_TOOLCHAIN_FILE a chance to set CMAKE_GENERATOR_TOOLSET. This
point is still early enough to set the generator toolset prior to
the initialization of any languages that might use the toolset.
The cmake::GeneratorToolset member variable remains an indication
of what was specified by the -T option or loaded from the cache.
It does not need to be updated based on the toolchain file setting.
The cmMakefile::TryCompile can still pass cmake::GeneratorToolset
into the inner instance because the try-compiled project will do
platform and language initialization using the CMakeSystem module
configured for the outer project.
Extend the RunCMake.GeneratorToolset test with cases that use a
toolchain file to set CMAKE_GENERATOR_TOOLSET.
Teach set_property and get_property an "INSTALL" property type to be
associated with install-tree file paths. Make the properties available
to CPack for use during packaging. Add a "prop_inst" Sphinx domain
object type for documentation of such properties.
Create a Modules/CMakeSystemSpecificInitialize.cmake module loaded after
CMakeSystem.cmake but before per-language initialization. Use it to
load an optional Platform/<os>-Initialize.cmake module. This will be
useful to do per-platform initialization that does not depend on the
language and use the results when enabling specific languages.
9407174b target_sources: New command to add sources to target.
81ad69e0 Make the SOURCES target property writable.
6e636f2e cmTarget: Make the SOURCES origin tracable.
3676fb49 cmTarget: Allow transitive evaluation of SOURCES property.
e6971df6 cmTarget: Make the source files depend on the config.
df753df9 cmGeneratorTarget: Don't add computed sources to the target.
869328aa cmComputeTargetDepends: Use valid config to compute target depends.
5de63265 Genex: Only evaluate TARGET_OBJECTS to determine target sources.
aa0a3562 cmGeneratorTarget: Compute target objects on demand
042c1c83 cmTarget: Compute languages from object libraries on demand.
fdcefe3c cmGeneratorTarget: Compute consumed object libraries on demand.
c355d108 cmComputeTargetDepends: Track object library depends.
e5da9e51 cmTarget: Allow any generator expression in SOURCES property.
5702e106 cmTarget: Include TARGET_OBJECTS genex in target SOURCES property.
857d30b5 cmGlobalGenerator: Add interface to call ForceLinkerLanguages
28e1d2f8 cmStringCommand: Add GENEX_STRIP subcommand.
bf98cc25 Genex: Evaluate TARGET_OBJECTS as a normal expression.
8cd113ad cmTarget: Store strings instead of cmSourceFile* to represent SOURCES.
4959f341 cmSourceFileLocation: Collapse full path for directory comparisons.
fcc92878 cmSourceFileLocation: Remove unused Update method.
59e8740a cmTarget: Remove AddSourceFile method
26d494ba cmTarget: Use string API to add sources to cmTarget objects.
d38423ec cmTarget: Add a method to obtain list of filenames for sources.
...
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.
Add a ComputeObjectMapping method to compute the object
names. It takes mapping to populate as an out-parameter so
that it can be extended in the future with parameters
relevant to generator expression evaluation.
Remove the supporting cmGeneratorTarget::AddObject method. It is
no longer needed as the container member is populated directly.
The ComputeObjectMapping method is called whenever objects are
requested from the cmGeneratorTarget. Because the Xcode generator
makes no such request, explicitly invoke the method from that
generator so that the logic of checking for bad sources in object
libraries is executed.
In a follow-up, the UseObjectLibraries usage may be replaced by a
true generator expression evaluator for TARGET_OBJECTS. That
will require generators to use cmGeneratorTarget::GetExternalObjects
which is not currently the case for Xcode and VS generators.
These policies are triggered by the use of a particular compiler rather
than outdated CMake code in a project. Avoid warning in every project
that enables a language by not displaying the policy warning by default.
Add variable CMAKE_POLICY_WARNING_CMP<NNNN> to control the warning
explicitly; otherwise enable the warning with --debug-output or --trace.
This breaks with strict policy convention because it does not provide
developers with any warning about the behavior change by default.
Existing projects will continue to build without a warning or change in
behavior. When a developer changes the minimum required version of
CMake in a project to a sufficiently high value (3.0), the project will
suddenly get the new compiler id and may break, but at least the
breakage comes with a change to the project rather than the version of
CMake used to build it.
Breaking strict policy convention is worthwhile in this case because
very few projects will be affected by the behavior change but every
project would have to see the warning if it were enabled by default.
Implement it in terms of the ComputeObjectFilenames virtual method
on the local generators.
Remove the reimplementation from the global generators which are
now all functionally identical.
Use the clang RemoveCStrCalls tool to automatically migrate the
code. This was only run on linux, so does not have any positive or
negative effect on other platforms.
Casts from std::string -> cmStdString were high on the list of things
taking up time. Avoid such implicit casts across function calls by just
using std::string everywhere.
The comment that the symbol name is too long is no longer relevant since
modern debuggers alias the templates anyways and the size is a
non-issue since the underlying methods are generated since it's
inherited.
Implement a Visitor to hold the sequence of source file tests
for populating outputs. Use VS 6 and 7 workaround from Brad
King for lack of partial template specialization and function
template specialization capabilities.
This will make it possible to use context dependent generator
expressions to determine the sources of a target.
In a follow-up, the list of sources will become dependent on
the config, so check for existence in cmTarget::GetSourceFiles
instead of up-front with cmGlobalGenerator::CheckTargets().
Brad King
Nils Gladitz
Geoff Viola
Ben Boeckel
Stephen Kelly