The InitializeAutogenTarget creates new targets and adds them to the
Targets container on the makefile. In this method, we have a reference
to that container and we are iterating over it. That happens to work
with hash_map, but it fails with undefined behavior when using the
std::unordered_map from libstdc++-4.9 (and likely others).
ce167b54 cmMakefile: Handle CMP0014 before configuring the generator.
7baef756 cmLocalGenerator: Assert that there is a parent.
63255342 cmMakefile: Remove redundant variable set.
894961af cmMakefile: Use the state to determine the parent directory.
115e9199 Use new top-level check abstraction.
c5059c90 cmLocalGenerator: Add abstraction to check if top-level.
b17686d2 cmGlobalGenerator: Move some flags from cmLocalGenerator.
ed41a8e7 cmLocalGenerator: Port loops to cmState::Snapshot.
48a9e91b cmState: Add an accessor for Parent snapshot and a validity check.
e7f7c2e2 cmLocalGenerator: Convert two recursive methods to loops.
c5cb3a73 cmLocalGenerator: Get project directories from the cmState.
76b59831 cmLocalGenerator: Initialize state before creating cmMakefile.
34c9ee2e cmLocalGenerator: Require a global generator in the constructor.
3837c483 Tests: Add case for 'ctest' run with bad CTestTestfile
b317b38d cmGlobalBorlandMakefileGenerator: Do not inherit from NMake generator
94867698 Don't use a cmLocalGenerator instance to call static methods.
...
If the CMakeLists.txt file does not exist, there must be a parent.
The case for the top-level of the project is already handled in
cmake::DoPreConfigureChecks.
The Borland generator re-implements every method the NMake generator
does, so there is no reason to inherit this way. Instead inherit
directly from cmGlobalUnixMakefileGenerator3 like all the other
makefile generators do.
KWSys upstream added an attribute to export .gitattributes so that
importing snapshots into the sources of other projects would bring along
the attributes. However, we don't want to export them from CMake.
Drop .gitattributes entries not relevant to CMake.
Teach the legacy two-argument signature to use CMAKE_CONFIG_TYPE
from the environment only if it is non-empty. This makes behavior
consistent with the main signature.
The find_package command, on Windows, has always searched build trees
recently visited by cmake-gui (or CMakeSetup at one time). This was
done when the command was created with the intention of simplifying
workflows involving building multiple dependent projects. However,
this behavior depends on recent developer interaction and therefore
can create different find results based on transient system states.
It can lead to surprising results and user confusion.
Since this behavior was first added CMake has gained many more search
options, better error messages when a package is not found, and a
package registry. The latter in particular allows projects to make
their build trees available for dependent projects to find without
user intervention. Therefore the originally intended workflow can
be achieved in other, more stable ways.
After the above evoluion of find_package we have now decided that
the magic search-where-cmake-gui-was behavior does more harm than
good. Drop it. We do not need a policy for this behavior change
because it only affects interactive use.
The GNU 4.8 standard library's cstdio header is not aware that C++14
honors C11's removal of "gets" from stdio.h and results in an error:
/.../include/c++/4.8/cstdio:120:11: error: no member named 'gets' in the global namespace
Detect this problematic case and default to using C++11 instead of
C++14 for building CMake itself.
20560e8d Ninja: Do not use newlines in response files with Windows GNU tools (#15439)
b3de0dfe Ninja: Use forward slashes for any GCC on Windows (#15439)
378c2a0e Ninja: Refactor detection of MinGW tools on Windows
957c2aac RC: Simplify selection of resource compiler based on C/C++ toolchain
