summaryrefslogtreecommitdiffstats
path: root/Source/cmNinjaTargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* cmLocalGenerator: Clarify GetIncludeFlags signatureBrad King2021-02-251-6/+8
| | | | | | | | | | | | | Make the `config` argument non-optional so all callers must be explicit. Convert the path style argument to an enumeration to make its role clear at call sites. The path style argument is implemented by `ConvertToIncludeReference`, which was introduced with the Ninja generator by commit 5b114c9bee (Introduce a cmLocalGenerator::ConvertToIncludeReference function, 2011-09-07, v2.8.7~187^2~4). Its only purpose is to allow the Ninja generator to use relative paths in `-I` flags. Add a comment explaining this role.
* Merge topic 'cpp-modules'Brad King2021-01-071-25/+108
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 39cbbb59a5 ninja: add experimental infrastructure to generate gcc-format modmap files 791b4d26d6 ninja: add experimental infrastructure to generate modmap files with dyndep 4b23359117 ninja: Add experimental infrastructure for C++20 module dependency scanning f814d3b3c6 cmNinjaTargetGenerator: use $OBJ_FILE for the object b0fc2993e1 Treat the '.mpp' file extension as C++ code 988f997100 cmScanDepFormat: Fix name of our internal tool in parse errors dacd93a2db ninja: De-duplicate version numbers required for ninja features 533386ca29 cmStandardLevelResolver: Factor out helper to capture stoi exceptions Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Ben Boeckel <ben.boeckel@kitware.com> Acked-by: Robert Maynard <robert.maynard@kitware.com> Acked-by: Shannon Booth <shannon.ml.booth@gmail.com> Merge-request: !5562
| * ninja: add experimental infrastructure to generate modmap files with dyndepBen Boeckel2021-01-051-4/+43
| | | | | | | | | | | | | | | | The scan step may need to output additional information for the compiler, not just the build tool. The modmap is assumed to be beside the object output. Additional refactoring may open up a channel to inform per-source paths to the dyndep rule in the future, but is not done here.
| * ninja: Add experimental infrastructure for C++20 module dependency scanningBrad King2021-01-051-20/+64
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Optionally enable this infrastructure through an undocumented `CMAKE_EXPERIMENTAL_CXX_MODULE_DYNDEP` variable. Currently this is experimental and intended for use by compiler writers to implement their scanning tools. Warn as such when the feature is activated. Later when compilers provide the needed scanning tools we can enable this variable from our corresponding compiler information modules. It is never meant to be set by project code. When enabled, generate a build graph similar to what we use for Fortran module dependencies. There are some differences needed because we can scan dependencies without explicit preprocessing, and can directly compile the original source afterward. Co-Author: Ben Boeckel <ben.boeckel@kitware.com>
| * cmNinjaTargetGenerator: use $OBJ_FILE for the objectBen Boeckel2021-01-051-1/+1
| | | | | | | | This will not be $out in all cases in the future.
* | Merge topic 'export-compile-commands-per-target'Brad King2021-01-071-1/+1
|\ \ | | | | | | | | | | | | | | | | | | a742b5d137 CMAKE_EXPORT_COMPILE_COMMANDS: allow configuration per target Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5651
| * | CMAKE_EXPORT_COMPILE_COMMANDS: allow configuration per targetShannon Booth2021-01-051-1/+1
| |/ | | | | | | | | | | | | | | The new target property `EXPORT_COMPILE_COMMANDS` associated with the existing global variable can be used to optionally configure targets for their compile commands to be exported. Fixes: #19462
* | Code style: add missed explicit 'this->'Oleksandr Koval2021-01-051-18/+22
|/ | | | | CMake uses explicit 'this->' style. Using custom clang-tidy check we can detect and fix places where 'this->' was missed.
* Merge topic 'ispc_control_header_suffixes'Brad King2020-12-151-1/+6
|\ | | | | | | | | | | | | c9a50f3556 ISPC: Generated Headers suffix configurable with a better default Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5597
| * ISPC: Generated Headers suffix configurable with a better defaultRobert Maynard2020-12-141-1/+6
| | | | | | | | | | | | | | | | | | The target property `ISPC_HEADER_SUFFIX` and associated global variable now can control the suffix used when generating the C/C++ interoperability ISPC headers. In addition the default suffix is now "_ispc.h" which matches the common convention that the ISPC compiler team uses and recommends.
* | Merge topic 'correct_ispc_path_computation'Brad King2020-12-081-6/+9
|\ \ | |/ | | | | | | | | | | | | 9af93fef11 ISPC: Handle OBJECT sources in different directories 72ae15ebcb ISPC: Ninja properly compute ISPC_HEADER_DIRECTORY location Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5581
| * ISPC: Ninja properly compute ISPC_HEADER_DIRECTORY locationRobert Maynard2020-12-071-6/+9
| |
* | Merge topic 'explicit-LANGUAGE-flag'Brad King2020-12-041-1/+9
|\ \ | | | | | | | | | | | | | | | | | | | | | 48aac247e9 Compile with explicit language flag when source LANGUAGE property is set 2e67a75acd Embarcadero: Simplify addition of -P flag for C++ Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5522
| * | Compile with explicit language flag when source LANGUAGE property is setBrad King2020-12-021-1/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This change was originally made by commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2), but it was reverted by commit 30aa715fac (Revert "specify language flag when source LANGUAGE property is set", 2020-11-19) to restore compatibility with pre-3.19 behavior. Implement the change again, but add policy CMP0119 to make this change while preserving compatibility with existing projects. Note that the `Compiler/{Clang,Intel,MSVC}-CXX` modules do not need to specify `-TP` for their MSVC-like variants because we already use the flag in `CMAKE_CXX_COMPILE_OBJECT`. Similarly for `Compiler/XL-CXX` and `Platform/Windows-Embarcadero`. Note also that this does not seem possible to implement for XL C. Even with `-qsourcetype=c`, `xlc` complains about an unknown suffix: `1501-218 (W) file /.../AltExtC.zzz contains an incorrect file suffix`. It returns non-zero even with `-qsuppress=1501-218`. Co-Author: Robert Maynard <robert.maynard@kitware.com> Fixes: #14516, #20716
* | | Ninja Generators: Homogenize configuration with MakefilesMarc Chevrier2020-12-011-38/+26
|/ / | | | | | | | | * Use same configuration variables to configure dependencies * Abstract Ninja deps format from compiler one
* | Refactoring: Introduce place-holder for dependency target.Marc Chevrier2020-11-281-2/+3
| | | | | | | | | | | | | | | | These changes are in preparation of compiler generated dependencies support for Makefiles generators * compiler output and dependency target can be different for Makefiles generators * resolve inconsistency naming for dependency file place-holder
* | Merge topic 'revert-explicit-LANGUAGE-flag'Brad King2020-11-201-10/+1
|\ \ | |/ | | | | | | | | | | 30aa715fac Revert "specify language flag when source LANGUAGE property is set" Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5519
| * Revert "specify language flag when source LANGUAGE property is set"Brad King2020-11-191-10/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit 74b1c9fc8e (Explicitly specify language flag when source LANGUAGE property is set, 2020-06-01, v3.19.0-rc1~722^2) and the lookup tables from its two immediate ancestors. The purpose of that change was to convert an explicit `LANGUAGE` source file property into an explicit language specification compiler flag like `-x c`. This seems reasonable since the property is documented as meaning "indicate what programming language the source file is". It is also needed to help compilers deal with non-standard source file extensions they don't recognize. However, some projects have been setting `LANGUAGE C` on `.S` assembler source files to mean "use the C compiler". Passing `-x c` for them breaks the build because the `.S` sources are not written in C. These projects should be updated to use `enable_language(ASM)`, for which CMake often chooses the C compiler as the assembler when using toolchains that support it (which would have to be the case for projects using the approach). Revert the change for now to preserve the old behavior for such projects. We can re-introduce it with a policy in a future version of CMake. Fixes: #21469 Issue: #14516, #20716
* | cmGlobalNinjaGenerator: use P1689 dependency file format for FortranBen Boeckel2020-11-171-1/+1
| | | | | | | | | | | | | | The module dependency specification format described in the C++ JTC1/SC22/WG21 paper [1] is also suitable for use by Fortran. [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p1689r2.html
* | cmNinjaTargetGenerator: Clarify variable names for preprocessing conditionsBrad King2020-11-061-17/+14
| | | | | | | | | | What is important about code paths for Fortran's explicit preprocessing is that the compilation step following it does not do preprocessing.
* | cmNinjaTargetGenerator: Simplify scan rule depfile selectionBrad King2020-11-061-30/+32
| | | | | | | | | | The depfile can always be the first output of the build statement with a `.d` suffix added. This approach easily avoids conflicts.
* | cmNinjaTargetGenerator: Generalize GetScanRule helperBrad King2020-11-061-30/+27
| | | | | | | | | | Allow the caller to provide any number of commands, and to choose which ones get a launcher.
* | cmNinjaTargetGenerator: Remove redundant conditions for dyndep blocksBrad King2020-11-061-26/+19
| | | | | | | | | | The GetScanCommand and GetScanBuildStatement helpers are called only in code paths for dyndep. Drop their checks for this condition.
* | cmNinjaTargetGenerator: Revise conditions to clarify dyndep code pathsBrad King2020-11-061-10/+8
| | | | | | | | | | | | All the scan-related code paths are actually about dyndep rather than explicit preprocessing. It just happens that the implementation for Fortran requires explicit preprocessing.
* | cmNinjaTargetGenerator: Clarify scan rule code groupingBrad King2020-11-061-24/+28
| |
* | cmNinjaTargetGenerator: Clarify scan rule helper functionsBrad King2020-11-061-73/+68
| | | | | | | | | | Revise names to clarify that these helpers are for the dependency scanning commands, which may happen to preprocess.
* | cmNinjaTargetGenerator: Drop unnecessary mutationBrad King2020-11-061-2/+2
| | | | | | | | GetPreprocessScanRule's caller always has `vars.Source` set to `$in`.
* | cmNinjaTargetGenerator: Clarify method namesBrad King2020-11-061-11/+10
| |
* | cmNinjaTargetGenerator: Consolidate redundant methodsBrad King2020-11-061-9/+3
| |
* | clang-tidy: allow OBJC and OBJCXXAndrew Fuller2020-11-051-7/+13
| |
* | cmLocalGenerator::GetRuleLauncher: return cmPropvvs314152020-11-021-2/+2
|/
* CUDA: Clang separable compilationRaul Tambre2020-09-241-3/+6
| | | | | | | | | | | | For NVCC the compiler takes care of device linking when passed the "-dlink" flag. Clang doesn't support such magic and requires the buildsystem to do the work that NVCC does behind the scenes. The implementation is based on Bazel's device linking documentation: https://github.com/tensorflow/tensorflow/blob/7cabcdf073abad8c46e9dda62bb8fa4682d2061e/third_party/nccl/build_defs.bzl.tpl#L259 Closes: #20726
* ISPC: Support generation for multiple instruction setsRobert Maynard2020-09-041-0/+13
|
* ISPC: Add compiler launcher supportRobert Maynard2020-09-031-1/+1
|
* cmMakefile::GetDefinition: return cmPropVitaly Stakhovsky2020-09-021-12/+17
|
* Merge topic 'ispc_lang_support'Brad King2020-09-011-0/+37
|\ | | | | | | | | | | | | | | | | | | | | | | 5ece12b7e4 gitlab-ci: add ISPC to the Fedora CI image 8976817d6d ISPC: Update help documentation to include ISPC 2368f46ba4 ISPC: Support building with the MSVC toolchain e783bf8aa6 ISPC: Support ISPC header generation byproducts and parallel builds 34cc6acc81 Add ISPC compiler support to CMake 419d70d490 Refactor some swift only logic to be re-used by other languages Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !5065
| * ISPC: Support ISPC header generation byproducts and parallel buildsRobert Maynard2020-08-281-0/+37
| |
* | Add INTERFACE libraries to generated buildsystem if they have SOURCESBrad King2020-08-071-0/+1
|/ | | | | | | | | | | | | | | | | | | | | | | | INTERFACE libraries were created with the intention of collecting usage requirements for use by other targets via `target_link_libraries`. Therefore they were not allowed to have SOURCES and were not included in the generated buildsystem. In practice, this has become limiting: * Header-only libraries do have sources, they just do not compile. Developers should be able to edit those sources (the header files) in their IDE. * Header-only libraries may need to generate some of their header files via custom commands. Some projects work around these limitations by pairing each interface library with an `add_custom_target` that makes the header files and custom commands appear in the generated buildsystem and in IDEs. Lift such limitations by allowing INTERFACE libraries to have SOURCES. For those with sources, add a corresponding build target to the generated buildsystem. Fixes: #19145
* Source: use cmNonempty()Vitaly Stakhovsky2020-07-281-1/+1
|
* cmNonempty: Convenience inlines to check for non-empty stringVitaly Stakhovsky2020-07-141-10/+9
|
* cmMakefile: Refactor API to better handle empty config valuesRobert Maynard2020-07-031-1/+2
|
* Explicitly specify language flag when source LANGUAGE property is setRobert Maynard2020-06-091-1/+10
| | | | Fixes: #14516, #20716
* Merge topic 'cmprop'Brad King2020-06-021-0/+1
|\ | | | | | | | | | | | | b36d1bdd9d Single location for cmProp typedef Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4829
| * Single location for cmProp typedefVitaly Stakhovsky2020-06-011-0/+1
| |
* | GetDefinition: avoid duplicate callsVitaly Stakhovsky2020-05-291-3/+3
|/
* Merge topic 'fortran-preprocess-property'Brad King2020-05-221-127/+227
|\ | | | | | | | | | | | | | | | | | | 3888de23da Ninja: Skip Fortran preprocessing if Fortran_PREPROCESS is OFF 66c4e87282 Ninja: Add helper functions to generate Fortran build 5cca1ec893 Ninja: Add helper functions to generate Fortran preprocess rule b0a6161190 Fortran: Add Fortran_PREPROCESS property Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !4659
| * Ninja: Skip Fortran preprocessing if Fortran_PREPROCESS is OFFPeter Hill2020-05-211-10/+54
| | | | | | | | | | | | | | | | | | If `Fortran_PREPROCESS` is explicitly turned off for a source file then we know it does not need to be preprocessed. Teach the Ninja generator to skip preprocessing in this case. Otherwise we still must preprocess just in case. Fixes: #18870
| * Ninja: Add helper functions to generate Fortran buildPeter Hill2020-05-211-61/+87
| |
| * Ninja: Add helper functions to generate Fortran preprocess rulePeter Hill2020-05-211-69/+98
| |
| * Fortran: Add Fortran_PREPROCESS propertyPeter Hill2020-05-211-0/+1
| | | | | | | | Issue: #18870
generated by cgit v0.12 at 2025-01-07 18:25:37 (GMT)