| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Rather than making dummy backtraces and passing them around, just make
backtraces optional.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While tracing dependencies of a target, cmTargetTraceDependencies
follows sources by full path to determine if the source is to be
produced by a custom command. Commit 4959f341 (cmSourceFileLocation:
Collapse full path for directory comparisons., 2014-03-27) changed
the storage of target sources to be in the form of a normalized
path instead of an unnormalized path.
The path is followed by looking it up in a mapping via
cmMakefile::GetSourceFileWithOutput to acquire an appropriate
cmSourceFile. The mapping is populated with the OUTPUT components
of add_custom_command invocations, however it is populated with
unnormalized paths. This means that the tracing logic does not
find appropriate cmSourceFiles, and does not generate appropriate
build rules for the generated sources.
Normalize the paths in the OUTPUT components of add_custom_command
to resolve this.
The paths in the DEPENDS component of add_custom_command are also
not normalized, leading to the same problem again. Normalize the
depends paths after generator evaluation and expansion.
|
| |
|
|
|
|
|
| |
Rely on evaluation in cmCustomCommandGenerator for the generators.
When tracing target dependencies, depend on the union of dependencies
for all configurations.
|
| |
|
|
|
|
|
| |
Until now the cmCustomCommandGenerator was used only to compute the
command lines of a custom command. Generalize it to get the comment,
working directory, dependencies, and outputs of custom commands. Update
use in all generators to support this.
|
| |
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
|
|
|
| |
Most callers already have a std::string, on which they called c_str() to pass it
into these methods, which internally converted it back to std::string. Pass a
std::string directly to these methods now, avoiding all these conversions.
Those methods that only pass in a const char* will get the conversion to
std::string now only once.
|
| |
|
|
|
| |
The compiled generator expressions need to outlive the creating
type. For the same reason, store the input string in a std::string.
|
| |
|
|
|
|
|
|
|
|
| |
Removing the Process() API and removing the parameters from the
constructor will allow cmGeneratorExpressions to be cached and evaluated
with multiple configs for example, such as when evaluating target
properties. This requires the creation of a new compiled representation
of cmGeneratorExpression. The cmListFileBacktrace remains in the
constructor so that we can record where a particular generator
expression appeared in the CMakeLists file.
|
| |
|
|
|
|
|
|
|
| |
Evaluate in the COMMAND arguments of custom commands the generator
expression syntax introduced in commit d2e1f2b4 (Introduce "generator
expressions" to add_test, 2009-08-11). These expressions have a syntax
like $<TARGET_FILE:mytarget> and are evaluated during build system
generation. This syntax allows per-configuration target output files to
be referenced in custom command lines.
|
| |
|
|
|
|
| |
The cmCustomCommandGenerator::GetCommand method completely replaces the
purpose of this method. Re-implement GetRealLocation inline at the only
remaining call site and remove it.
|
|
|
The Makefile, VS, and Xcode generators previously duplicated some custom
command line generation code. Factor this out into a separate class
cmCustomCommandGenerator shared by all generators.
|
