7657e8b1 cmMakefile: Introduce a local cmMakefile variable.
4e8f242d cmMakefile: Store unconfigured cmMakefiles.
d65e0123 cmMakefile: Implement ConfigureSubDirectory in terms of cmMakefile.
f059ed16 cmMakefile: Move Configure responsibility from cmLocalGenerator.
a653611d cmake: Replace CurrentLocalGenerator concept with CurrentMakefile.
69a038a9 cmMakefile: Refactor directories specified with the subdirs command.
08637970 cmLocalGenerator: ComputeObjectMaxPath just before generating.
27e11c6f Merge Configure state with GeneratingBuildSystem state.
363caa2f cmLocalGenerator: De-virtualize Configure().
Compute deterministic GUIDs that are unique to the build tree by
hashing the path to the build tree with the GUID logical name.
Avoid storing them in the cache, but honor any found there.
This will allow project GUIDs to be reproduced in a fresh build
tree so long as its path is the same as the original, which may
be useful for incremental builds.
Refactor the local generator creation API to accept a
cmState::Snapshot. Adjust MakeLocalGenerator to use the 'current'
snapshot in cases where there is no parent. Create the snapshot
for subdirectories in cmMakefile::AddSubdirectory.
This means that snapshots are now created at the point of extending the tree,
as appropriate, and independently of the cmLocalGenerator and cmMakefile they
represent the state for.
d7923b82 Use std::unordered_map instead of hash_map where available.
820777af Tests: Don't rely on ordering of targets in maps.
921d74d8 AutoGen: Don't iterate over a container while populating it.
Revert the refactoring by commit v2.8.11~105^2~1 (Ninja: use MinGW
generator code in EnableLanguage, 2013-03-09) and move the MinGW-
specific logic back to the "MinGW Makefiles" generator. Instead teach
the platform information modules for GNU and MSVC on Windows to set the
preferred RC compiler just before enabling the RC language. This way
we choose the RC compiler based on the C/C++ toolchain that is actually
enabled.
In commit 74de9a73 (cmGlobalGenerator: Delegate storage of enabled
languages to cmState, 2015-04-11) the original LanguageEnabled
member of cmGlobalGenerator was left behind by mistake. One use
of it in EnableLanguagesFromGenerator (for try_compile) was left,
but the member is not populated anymore. Drop the member and
teach EnableLanguagesFromGenerator to copy the list of enabled
languages from one cmState to the other.
Reported-by: Matt McCormick <matt.mccormick@kitware.com>
The Ninja build system does not support a in-file verbositiy switch.
Instead teach 'cmake --build' to extract the CMAKE_VERBOSE_MAKEFILE
setting and pass it as an optional '-v' argument to Ninja. This can
serve as a reasonable fallback.
Signed-off-by: Gregor Jasny <gjasny@googlemail.com>
We use cmGlobalGenerator::GetDirectoryContent to avoid repeating
directory listings. However, GetDirectoryContent loads content from
disk at most once. This breaks find_library calls that occur when disk
content has changed since preceding find_library calls.
Teach cmGlobalGenerator::GetDirectoryContent to save the directory
modification time when content is loaded and re-load content if it
changes.
Create a RunCMake.find_library test with a case covering this.
Provide options to fail without blocking or to block up to a timeout.
Provide options to specify the scope containing the lock so it can be
released automatically at the end of a function, file, or process.
Extend the RunCMake.file test with cases covering the file(LOCK) command
usage and error cases.
The evaluation files must be known before cmTargetTraceDependencies
attempts to find them, but we must actually generate the files after
cmTargetTraceDependencies, as that can add to target SOURCES. The
limitation is that the generated output name must not depend on the
SOURCES of a target if the generated file is used by that target.
Mark the output files as GENERATED so that trace dependencies does
not expect them to already exist in the filesystem.
Move the invokation of ForceLinkerLanguage in the Generate logic
to after the generated file names are known. ForceLinkerLanguage
tries to determine the sources of a target (in order to determine
an already-known language) and otherwise fails to get information
about the generated file.
Test that the output of file(GENERATE) can be used as a target source
file and that accessing the target SOURCES in the name of the output
file is an error. Accessing the TARGET_OBJECTS would be a similar
error if it was legal to use that generator expression in this
context. That is not currently possible and is a different error
condition, so test the current error output as a reminder to change
the expected output if that becomes possible in the future. Test
that generated rule files resulting from cmTargetTraceDependencies
appear in the SOURCES generated in the output file.
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.
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.
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.
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.
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.
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.
Stephen Kelly
Brad King
Gregor Jasny
Ruslan Baratov
Peter Collingbourne
Geoff Viola
Nils Gladitz
Ben Boeckel