The execution file path stack and the backtrace stack are kept in sync.
At all call sites of `GetExecutionFilePath`, the execution file path
matches the path in the context at the top of the backtrace stack.
The only call sites that pass the explicit file name argument are in
function blocker `ArgumentsMatch` methods for `function` and `macro`.
We already ensure that they are balanced within a file scope, and the
RAII helpers `BuildsystemFileScope` and `ListFileScope` ensure that the
backtrace and execution list file stacks unwind to the matching level.
Therefore we can assume that the file name where we are checking for
matching arguments matches starting file name where those arguments
first appeared, and do not need to pass it explicitly.
#pragma once is a widely supported compiler pragma, even though it is
not part of the C++ standard. Many of the issues keeping #pragma once
from being standardized (distributed filesystems, build farms, hard
links, etc.) do not apply to CMake - it is easy to build CMake on a
single machine. CMake also does not install any header files which can
be consumed by other projects (though cmCPluginAPI.h has been
deliberately omitted from this conversion in case anyone is still using
it.) Finally, #pragma once has been required to build CMake since at
least August 2017 (7f29bbe6 enabled server mode unconditionally, which
had been using #pragma once since September 2016 (b13d3e0d)). The fact
that we now require C++11 filters out old compilers, and it is unlikely
that there is a compiler which supports C++11 but does not support
#pragma once.
This option has been broken since commit b9f9915516 (cmMakefile: Remove
VarUsageStack., 2015-05-17, v3.3.0-rc1~52^2). That commit removed the
check that an initialized variable has actually been used and caused the
option to warn on every variable ever set. This was not caught by the
test suite because the test for the feature only checked that warnings
appear when needed and not that they do not appear when not needed.
The option was never very practical to use. Remove it to avoid the
runtime cost of usage tracking and checks for every variable (which we
were doing even when the option was not used).
Adds a flag to indicate that pipe output from a custom command should be
interpreted as UTF-8 encoded. This change does not introduce a public
way to set the flag, but generators that create internally-generated
commands know if they are calling cmake, which uses UTF-8 pipes.
MSBuild added support for interpreting output of PreBuildEvent,
PreLinkEvent, PostBuildEvent, and CustomBuildStep as UTF-8. This change
will appear in Visual Studio 16.6 Preview 3. It is opt-in, and you need
to add the StdOutEncoding tag. MSBuild treats these as property bags so
if we emit the tag for earlier versions of Visual Studio it would be
safely ignored. This change emits the StdOutEncoding tag and sets it to
UTF-8 whenever the custom command UTF-8 pipe flag is set. This fixes
globalization issues when the output from cmake contained characters
that required MSBuild to interpret as UTF-8 before displaying them.
CMake 3.16 and below allow multiple `export()` calls with the same output
file even without using `APPEND`. The implementation worked by accident
by leaking memory. Refactoring in commit 5444a8095d (cmGlobalGenerator:
modernize memrory managemenbt, 2019-12-29, v3.17.0-rc1~239^2) cleaned up
that memory leak and converted it to a use-after-free instead.
The problem is caused by using the `cmGlobalGenerator::BuildExportSets`
map to own `cmExportBuildFileGenerator` instances. It can own only
one instance per output FILE name at a time, so repeating use of the
same file now frees the old `cmExportBuildFileGenerator` instance
and leaves the pointer in the `cmMakefile::ExportBuildFileGenerators`
vector dangling. Move ownership of the instances into `cmMakefile`'s
vector since its entries are not replaced on a repeat output FILE.
In future work we should introduce a policy to error out on this case.
For now simply fix the use-after-free to restore CMake <= 3.16 behavior.
Fixes: #20469
Enable debug messages a new `--find-debug` command-line option or via
the `CMAKE_FIND_DEBUG_MODE` variable.
This work was started by Chris Wilson, continued by Ray Donnelly, and
then refactored by Robert Maynard to collect information into a single
message per find query.
Co-Author: Ray Donnelly <mingw.android@gmail.com>
Co-Author: Chris Wilson <chris+github@qwirx.com>
Move custom command creation to cmLocalGenerator and dispatch custom
commands in cmMakefile to generate time. Generators add custom commands
using the new methods provided by cmLocalGenerator.
Issue: #12877
dd0f304613 Objective C/C++: Add compiler standard detection
b515af782b Help: Add release note for Objective-C/C++ language support
9e66397c28 Languages: Add support for Objective-C++
80f120a85f Languages: Add support for Objective-C
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3811
0e1faa28cb cmMakefile: Separate custom command setup from actual creation
56c204e8eb cmMakefile: Refactor AddCustomCommandOldStyle to be delay friendly
3061dc6ac9 add_custom_command: Add tests for rejecting literal quotes in commands
e893ab94ba cmMakefile: Validate command line for all custom commands
f1e846fdde cmMakefile: Extract custom command validation method
4926ab2454 cmMakefile: Create all generated byproducts as known sources
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !3822
Provide a standardized way to handle the C++ "standard" headers
customized to be used with current CMake C++ standard constraints.
Offer under directory `cm` headers which can be used as direct
replacements of the standard ones. For example:
#include <cm/string_view>
can be used safely for CMake development in place of the `<string_view>`
standard header.
Fixes: #19491
