The cmMakefile should get a fully prepared snapshot and not clobber its
definitions. It should eventually be able to process list files from any
starting-point snapshot, though that is some refactoring away still.
The changes in commit c96fe0b4 (cmake: Add -W options to control
deprecation warnings and errors, 2015-07-28) fail to account for
-Wdev warnings produced by places in CMake other than message().
This causes a regression in which -Wno-dev fails to suppress such
warnings. Revert the feature until it can be revised accordingly.
heaptrack showed a 1 byte allocation with the backtrace pointing
here, as is the case since commit v3.3.0-rc1~112^2~5 (cmPolicies:
Remove unused cmPolicy class., 2015-05-03)
The logic in commit c96fe0b4 (cmake: Add -W options to control
deprecation warnings and errors, 2015-07-28) accidentally enables
errors on warnings by default in scripts because there is no
initialization of CMAKE_SUPPRESS_DEVELOPER_ERRORS to TRUE.
Rename internal CMAKE_SUPPRESS_DEVELOPER_ERRORS cache entry to
CMAKE_ERROR_DEVELOPER_WARNINGS. Fix the logic in the message() command
to treat AUTHOR_WARNING as an error only if the option is explicitly
enabled.
Refactor the -Wdev and -Wno-dev to use a generic -W parser that follows
the GCC pattern. Include support for setting CMAKE_ERROR_DEPRECATED and
CMAKE_WARN_DEPRECATED via the deprecated warning. Add -Werror=dev and
-Wno-error=dev options so that dev warning options are in line with
deprecated warning options. Use a new CMAKE_SUPPRESS_DEVELOPER_ERRORS
internal cache entry to store the above new dev options persistently.
Add tests for new options and updated cmake documentation and release
notes to list new options.
57f03e59 Port some of the cmExportFileGenerator API to cmGeneratorTarget.
57ab0f70 Port cmExportBuildFileGenerator to cmGeneratorTarget.
570938cb cmExportTryCompileFileGenerator: Create cmGeneratorTargets.
ec38e4c8 Move GetFullPath to cmGeneratorTarget
dfb025bf Move GetLocationForBuild to cmGeneratorTarget.
9f2dca80 Move GetLocation to cmGeneratorTarget.
c7a8e74b Always access target location from a cmGeneratorTarget instance.
5b60eaf6 cmTarget: Restore the ImportedGetLocation method.
50b17a61 cmIncludeCommand: Populate the cmGeneratorTargets in deprecated path.
ba266858 cmTarget: Create cmGeneratorTargets before reading deprecated LOCATION.
5ab3a946 cmTarget: Inline GetLocation into deprecated callers.
496f4cd0 cmGlobalGenerator: Create cmGeneratorTargets before QtAutomoc.
de80993a cmGlobalGenerator: Create cmGeneratorTargets earlier.
611220f7 cmTarget: Use reliable test for CMP0024 and CMP0026 OLD.
bbad6ba5 cmLocalGenerator: Remove unused AddCustomCommandToCreateObject method.
e4dc83ad cmLocalGenerator: Remove unused AddBuildTargetRule method.
...
The --trace option is helpful, but sometimes, what you're looking for is
deep under many layers of function calls and figuring out what instance
of the function call you're looking at is tedious to determine (usually
involving patching and message()). Instead, add a --trace-expand option
to trace while expanding commands into what CMake actually sees.
Since commit v2.4.0~4158 (When the initially configured generator is
invalid, allow the user to change the generator without deleting the cache
by hand, 2003-05-13) we remove CMAKE_GENERATOR from the cache if an error
occurs and CMAKE_MAKE_PROGRAM is not cached. This worked at the time
because all generators initialized the CMAKE_MAKE_PROGRAM cache entry.
Since commit v3.0.0-rc1~260^2~4 (VS: Switch to internal CMAKE_MAKE_PROGRAM
lookup by generators, 2013-11-15) and commit v3.2.0-rc1~39^2 (Xcode:
Switch to internal CMAKE_MAKE_PROGRAM lookup by generator, 2015-01-28) the
VS and Xcode generators no longer store CMAKE_MAKE_PROGRAM in the cache.
Therefore any error during generation would wipe out CMAKE_GENERATOR from
the cache and cause the next configuration to choose a default generator.
Simply drop the behavior introduced by the original commit and always
preserve CMAKE_GENERATOR. Since the time that behavior was introduced a
lot more state is now saved in CMakeCache.txt and CMakeFiles/ during the
initial configuration so it is not safe to change generators without
starting fresh anyway.
The test for this variable was removed in commit v2.8.8~330^2~7 (complex:
Remove ancient unused ComplexRelativePaths test, 2011-12-23).
Commit v3.1.0-rc1~425^2~2 (backtrace: Convert to local paths in
IssueMessage, 2014-03-12) appears to have accidentally made some backtraces
print relative paths with the variable because conversions which used to be
done at configure time, before the variable had an effect are now potentially
done at generate time.
The documentation of the variable says not to use it, and the docs are wrong in
that the variable actually applies in per-directory scope.
The read of the variable makes it harder to split conversion methods from
cmLocalGenerator where they don't belong. Remove it now.
Currently cmMakefile calls MakeRelative on a copy of the backtrace,
emits the copy to the stream once, then discards the copy. There
is no need to have API for the path conversion.
Don't create a snapshot in Initialize(), but leave the creation
responsibility to the cmake instance instead. Previously, the
cmState would Initialize() in its constructor, and the cmake instance
would re-Initialize() during Configure(). The end result was the
same and there would be one snapshot present. However, cmLocalGenerator
also created a snapshot on construction, and that one was used, leaving
the first snapshot unused, and potential for off-by-one errors.
Fix that by making the cmLocalGenerator use the existing snapshot
if it is top-level. Add a CurrentSnapshot to the cmake instance and
populated it while configuring a directory. This will eventually
replace the 'current local generator' concept. Fix the GetParent
implementation to be able to return the first snapshot.
This reverts commit f85db2f323.
Discussion by the QtCreator community at
https://bugreports.qt.io/browse/QTCREATORBUG-13695
raises concerns about this particular approach to working with CMake
projects using QtCreator. Also, the functionality and design of the QBS
extra generator was never discussed on the CMake mailing list or with
QtCreator developers. There may be better ways to make the two tools
work together.
In order to avoid committing to long-term support of this generator
prior to such discussion taking place, revert it from CMake for now.
We may restore this or use an alternative design based on results of
such discussion.
Stephen Kelly
Brad King
Clinton Stimpson
Michael Scott
Ben Boeckel