summaryrefslogtreecommitdiffstats
path: root/Source/cmCustomCommandGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* add_custom_{command,target}: Add COMMAND_EXPAND_LISTS optionEd Branch2017-01-141-9/+23
| | | | | | This option allows lists generated by generator expressions to be expanded. Closes: #15935
* Fix custom command target substitution with CROSSCOMPILING_EMULATORBrad King2016-10-281-13/+32
| | | | | | | | | | | | In commit v3.6.0-rc1~88^2 (CustomCommandGenerator: Add support for CROSSCOMPILING_EMULATOR, 2016-05-04) logic was introduced to substitute a target's `CROSSCOMPILING_EMULATOR` for argv0 in a custom command. However, it broke the case when the argv0 was a target name and now fails to expand the target name to its location at the same time as inserting the emulator. Fix the latter case. Inspired-by: Brian Maher <brian@brimworks.com> Closes: #16288
* cmState: Port dependents to new cmStateTypes headerStephen Kelly2016-10-191-1/+1
|
* cmState: Move TargetType enum to separate namespaceStephen Kelly2016-10-191-3/+3
|
* Simplify CMake per-source license noticesBrad King2016-09-271-11/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Per-source copyright/license notice headers that spell out copyright holder names and years are hard to maintain and often out-of-date or plain wrong. Precise contributor information is already maintained automatically by the version control tool. Ultimately it is the receiver of a file who is responsible for determining its licensing status, and per-source notices are merely a convenience. Therefore it is simpler and more accurate for each source to have a generic notice of the license name and references to more detailed information on copyright holders and full license terms. Our `Copyright.txt` file now contains a list of Contributors whose names appeared source-level copyright notices. It also references version control history for more precise information. Therefore we no longer need to spell out the list of Contributors in each source file notice. Replace CMake per-source copyright/license notice headers with a short description of the license and links to `Copyright.txt` and online information available from "https://cmake.org/licensing". The online URL also handles cases of modules being copied out of our source into other projects, so we can drop our notices about replacing links with full license text. Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority of the replacements mechanically. Manually fix up shebang lines and trailing newlines in a few files. Manually update the notices in a few files that the script does not handle.
* fix a load of include-what-you-use violationsDaniel Pfeifer2016-09-031-0/+7
|
* Avoid using KWSys auto_ptr by adopting it ourselvesBrad King2016-06-291-2/+2
| | | | | | | | | | | | Replace use of cmsys::auto_ptr with a CM_AUTO_PTR macro that maps to our own implementation adopted from the KWSys auto_ptr implementation. Later we may be able to map CM_AUTO_PTR to std::auto_ptr on compilers that do not warn about it. Automate the client site conversions: git grep -l auto_ptr -- Source/ | grep -v Source/kwsys/ | xargs sed -i \ 's|cmsys::auto_ptr|CM_AUTO_PTR|;s|cmsys/auto_ptr.hxx|cm_auto_ptr.hxx|'
* use CM_NULLPTRDaniel Pfeifer2016-06-281-1/+1
|
* Revise C++ coding style using clang-formatKitware Robot2016-05-161-64/+47
| | | | | | | | | | | | | Run the `Utilities/Scripts/clang-format.bash` script to update all our C++ code to a new style defined by `.clang-format`. Use `clang-format` version 3.8. * If you reached this commit for a line in `git blame`, re-run the blame operation starting at the parent of this commit to see older history for the content. * See the parent commit for instructions to rebase a change across this style transition commit.
* Remove `//------...` horizontal separator commentsBrad King2016-05-091-12/+0
| | | | | | | | | | | | | | | | | | | | | | | | Modern editors provide plenty of ways to visually separate functions. Drop the explicit comments that previously served this purpose. Use the following command to automate the change: $ git ls-files -z -- \ "*.c" "*.cc" "*.cpp" "*.cxx" "*.h" "*.hh" "*.hpp" "*.hxx" | egrep -z -v "^Source/cmCommandArgumentLexer\." | egrep -z -v "^Source/cmCommandArgumentParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmDependsJavaLexer\." | egrep -z -v "^Source/cmDependsJavaParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmExprLexer\." | egrep -z -v "^Source/cmExprParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmFortranLexer\." | egrep -z -v "^Source/cmFortranParser(\.y|\.cxx|Tokens\.h)" | egrep -z -v "^Source/cmListFileLexer\." | egrep -z -v "^Source/cm_sha2" | egrep -z -v "^Source/(kwsys|CursesDialog/form)/" | egrep -z -v "^Utilities/(KW|cm).*/" | xargs -0 sed -i '/^\(\/\/---*\|\/\*---*\*\/\)$/ {d;}' This avoids modifying third-party sources and generated sources.
* CustomCommandGenerator: Add support for CROSSCOMPILING_EMULATORJean-Christophe Fillion-Robin2016-05-091-2/+32
| | | | | | Teach the `add_custom_command` and `add_custom_target' commands to substitute argv0 with the crosscompiling emulator if it is a target with the `CROSSCOMPILING_EMULATOR` property set.
* Format include directive blocks and ordering with clang-formatBrad King2016-04-291-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Sort include directives within each block (separated by a blank line) in lexicographic order (except to prioritize `sys/types.h` first). First run `clang-format` with the config file: --- SortIncludes: false ... Commit the result temporarily. Then run `clang-format` again with: --- SortIncludes: true IncludeCategories: - Regex: 'sys/types.h' Priority: -1 ... Commit the result temporarily. Start a new branch and cherry-pick the second commit. Manually resolve conflicts to preserve indentation of re-ordered includes. This cleans up the include ordering without changing any other style. Use the following command to run `clang-format`: $ git ls-files -z -- \ '*.c' '*.cc' '*.cpp' '*.cxx' '*.h' '*.hh' '*.hpp' '*.hxx' | egrep -z -v '(Lexer|Parser|ParserHelper)\.' | egrep -z -v '^Source/cm_sha2' | egrep -z -v '^Source/(kwsys|CursesDialog/form)/' | egrep -z -v '^Utilities/(KW|cm).*/' | egrep -z -v '^Tests/Module/GenerateExportHeader' | egrep -z -v '^Tests/RunCMake/CommandLine/cmake_depends/test_UTF-16LE.h' | xargs -0 clang-format -i This selects source files that do not come from a third-party. Inspired-by: Daniel Pfeifer <daniel@pfeifer-mail.de>
* Use IsImported from cmGeneratorTarget.Stephen Kelly2015-10-161-1/+1
|
* cmState: Move TargetType enum from cmTarget.Stephen Kelly2015-10-141-1/+1
| | | | | | | Mostly automated: values=( "EXECUTABLE" "STATIC_LIBRARY" "SHARED_LIBRARY" "MODULE_LIBRARY" "OBJECT_LIBRARY" "UTILITY" "GLOBAL_TARGET" "INTERFACE_LIBRARY" "UNKNOWN_LIBRARY" "TargetType") for i in "${values[@]}"; do git grep -l cmTarget::$i | xargs sed -i "s|cmTarget::$i|cmState::$i|g"; done
* cmLocalGenerator: Store cmGeneratorTargets.Stephen Kelly2015-10-141-1/+1
| | | | Relieve cmMakefile of this responsibility.
* cmGeneratorExpression: Port to cmLocalGenerator.Stephen Kelly2015-10-121-4/+3
|
* Remove some needless GetMakefile() calls.Stephen Kelly2015-10-101-1/+1
|
* Move GetLocation to cmGeneratorTarget.Stephen Kelly2015-07-271-1/+1
|
* Always access target location from a cmGeneratorTarget instance.Stephen Kelly2015-07-271-3/+4
|
* cmCustomCommandGenerator: Require cmLocalGenerator in API.Stephen Kelly2015-07-271-9/+13
|
* Genex: Store a backtrace, not a pointer to one.Stephen Kelly2015-07-171-1/+1
| | | | | | | | | | The storage of a pointer means that the ownership and lifetime are externally determined, which is harder to reason about. It also imposes API constraints, requiring APIs to return references to backtraces. This pointer storage was introduced in commit v3.1.0-rc1~425^2~3 (genex: remove the need for backtraces, 2014-05-23). As backtraces are now cheap to copy around, just do that instead.
* cmCustomCommandGenerator: Port to cmOutputConverter.Stephen Kelly2015-06-061-3/+4
|
* cmLocalGenerator: Remove EscapeForShellOldStyle to only caller.Stephen Kelly2015-05-141-1/+30
|
* Add an option for explicit BYPRODUCTS of custom commands (#14963)Brad King2014-11-141-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | A common idiom in CMake-based build systems is to have custom commands that generate files not listed explicitly as outputs so that these files do not have to be newer than the inputs. The file modification times of such "byproducts" are updated only when their content changes. Then other build rules can depend on the byproducts explicitly so that their dependents rebuild when the content of the original byproducts really does change. This "undeclared byproduct" approach is necessary for Makefile, VS, and Xcode build tools because if a byproduct were listed as an output of a rule then the rule would always rerun when the input is newer than the byproduct but the byproduct may never be updated. Ninja solves this problem by offering a 'restat' feature to check whether an output was really modified after running a rule and tracking the fact that it is up to date separately from its timestamp. However, Ninja also stats all dependencies up front and will only restat files that are listed as outputs of rules with the 'restat' option enabled. Therefore an undeclared byproduct that does not exist at the start of the build will be considered missing and the build will fail even if other dependencies would cause the byproduct to be available before its dependents build. CMake works around this limitation by adding 'phony' build rules for custom command dependencies in the build tree that do not have any explicit specification of what produces them. This is not optimal because it prevents Ninja from reporting an error when an input to a rule really is missing. A better approach is to allow projects to explicitly specify the byproducts of their custom commands so that no phony rules are needed for them. In order to work with the non-Ninja generators, the byproducts must be known separately from the outputs. Add a new "BYPRODUCTS" option to the add_custom_command and add_custom_target commands to specify byproducts explicitly. Teach the Ninja generator to specify byproducts as outputs of the custom commands. In the case of POST_BUILD, PRE_LINK, and PRE_BUILD events on targets that link, the byproducts must be specified as outputs of the link rule that runs the commands. Activate 'restat' for such rules so that Ninja knows it needs to check the byproducts, but not for link rules that have no byproducts.
* genex: remove the need for backtracesBen Boeckel2014-06-051-1/+1
| | | | | Rather than making dummy backtraces and passing them around, just make backtraces optional.
* add_custom_command: Normalize OUTPUT and DEPENDS paths.Stephen Kelly2014-05-281-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | 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.
* add_custom_command: Evaluate generator expressions in DEPENDSStephen Kelly2014-03-201-2/+16
| | | | | | | Rely on evaluation in cmCustomCommandGenerator for the generators. When tracing target dependencies, depend on the union of dependencies for all configurations.
* Generalize cmCustomCommandGenerator to more fieldsBrad King2014-03-121-0/+24
| | | | | | | 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.
* Remove some c_str() calls.Stephen Kelly2014-03-111-2/+2
| | | | | | 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.
* stringapi: Pass configuration names as stringsBen Boeckel2014-03-081-1/+1
|
* cmMakefile: make some methods take const std::string& instead of const char*Rolf Eike Beer2014-01-161-1/+1
| | | | | | | | 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.
* Use cmsys::auto_ptr to manage cmCompiledGeneratorExpressionsStephen Kelly2012-12-201-2/+2
| | | | | The compiled generator expressions need to outlive the creating type. For the same reason, store the input string in a std::string.
* cmGeneratorExpression: Port users to two-stage processingStephen Kelly2012-09-181-3/+4
| | | | | | | | | | 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.
* Introduce "generator expression" syntax to custom commands (#11209)Brad King2010-12-151-3/+11
| | | | | | | | | 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.
* Remove cmLocalGenerator::GetRealLocationBrad King2010-12-081-1/+7
| | | | | | The cmCustomCommandGenerator::GetCommand method completely replaces the purpose of this method. Re-implement GetRealLocation inline at the only remaining call site and remove it.
* Factor out common custom command generatorBrad King2010-12-081-0/+58
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.
generated by cgit v0.12 at 2024-10-13 16:05:03 (GMT)