summaryrefslogtreecommitdiffstats
path: root/Source/cmNinjaNormalTargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* CreateRulePlaceholderExpander(): enhance memory managementMarc Chevrier2023-05-041-8/+8
| | | | This method returns now a std::unique_ptr instance rather than a raw pointer.
* Link step: use linker dependency linker fileMarc Chevrier2023-05-031-0/+15
| | | | | | Based on work done by @ben.boeckel (!8051) Fixes: #22217
* CMake code rely on cmList class for CMake lists management (part. 2)Marc Chevrier2023-04-291-12/+12
|
* Merge topic 'CMake-uses-cmList-class'Brad King2023-04-251-1/+2
|\ | | | | | | | | | | | | | | e08ba229ee CMake code rely on cmList class for CMake lists management (part. 1) 51b0d45d91 cmExpandList and cmExpandLists rely on cmList class Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8423
| * CMake code rely on cmList class for CMake lists management (part. 1)Marc Chevrier2023-04-241-1/+2
| |
* | Add support of CMAKE_<LANG>_USE_RESPONSE_FILE_FOR_LIBRARIES variable.Matthieu Ribiere2023-04-131-4/+34
|/ | | | | | We add a function in cmNinjaNormalTargetGenerator.cxx to check for the state of the option (as it was done for Makefile). This will be checked to add or not the `$LINK_PATH` and `$LINK_LIBRARIES` to the Ninja file. The default behavior is adding those libraries. Fixes: #24681
* Apple: Handle generation and comsuption of text-based stubs (.tbd files)Marc Chevrier2023-03-011-2/+102
| | | | Fixes: #24123
* RULE_LAUNCH_*: Add support for generator expressionsKyle Edwards2023-02-031-6/+6
|
* Ninja: Swift: Add dependency edge to swiftmodule fileEvan Wilde2023-01-211-0/+17
| | | | | | | | | | | | | | | | | | | | | | Swiftmodules act like headers for Swift, but are generated by the compiler while building the module. Unlike headerfiles in a pure C/C++ world, where the compiler generates the appropriate depfile. We don't have We're already adding the swiftmodule as an output from swift-linked targets, but aren't using that on inputs. This dependency edge is most important for static libraries in incremental builds. Suppose we have two static libraries, A, and B, and an executable E. B "links" against A, and E links against B. In a C/C++ environment, the library link dependency edge will run from E to both A and B, but there won't be an edge from B to A. If A is changed, the only way this should affect B is if the public interface changes, in which case, the headers will also change. The dep file contains the header link, so Ninja will rebuild B when appropriate. With Swift in an incremental build, B sees the order-dependency on A, but A already exists. If A is changed in a way that changes the public interface, the swiftmodule will change, but since we don't track it, we don't rebuild B, resulting in the final executable to fail to link.
* Ninja: NFC: refactor swift module name computationsEvan Wilde2023-01-211-25/+35
| | | | | | | | | In order to handle determining the swiftmodule name to add to the ninja dependency graph, we'll need to be able to compute the swiftmodule name for the dependency target, not just the current target. This patch refactors the computation of the module name out of inaccessible lambdas and into static functions that can compute the swiftmodule name from the generator and the target.
* Merge topic 'ninja-swift-exported-executables'Brad King2023-01-201-8/+2
|\ | | | | | | | | | | | | 4165eb3d0b Ninja: Emit swiftmodule from executable with exports Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8048
| * Ninja: Emit swiftmodule from executable with exportsEvan Wilde2023-01-191-8/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for tracking the swiftmodules for executables exporting symbols. This fixes a bug in the earlier implementation around emitting the swiftmodule. Previously, the code would use `CMAKE_EXE_EXPORTS_Swift_FLAG` to inject the `-emit-module`, and module path information into the `CMAKE_Swift_LINK_EXECUTABLE` rule. Because Swift skips the build step and only runs during the link phase, these flags were injected in `cmNinjaNormalTargetGenerator::ComputeLinkCmd` instead of `cmLocalGenerator::GetTargetFlags` where it is done normally. Unfortunately, injecting in `ComputeLinkCmd` didn't do anything because we have a `linkCmd` so `ComputeLinkCmd` exits early, before the EXE_EXPORT flags get added to the link command. Instead of playing with that flag, CMake checks `CMAKE_Swift_LINK_EXECUTABLE_WITH_EXPORTS` and uses that as the link rule if it exists and falls back on `CMAKE_Swift_LINK_EXECUTABLE`. I've defined that variable in terms of `CMAKE_Swift_LINK_EXECUTABLE` with the necessary additional flags for emitting the swift module instead. This has the same end effect as the desired behavior, but simplifies things a bit. Since we're generating the swiftmodule for executables with exports, I've also updated the dependency graph to include the swiftmodule as an output in the build dependency graph if the executable has exports. Tests updated: - RunCMake/NoWorkToDo: Ensure that the build graph does not result in unnecessary rebuilds with exporting executables. - SwiftOnly: Ensure that we can consume functions defined in the executable by a library getting linked into said executable.
* | cmGeneratorTarget: Cache full name componentsPierre Testart2023-01-181-5/+3
|/ | | | | Cache the result of cmGeneratorTarget::GetFullNameInternalComponents to improve performance.
* cmNinjaNormalTargetGenerator: use `cmStrCat`Ben Boeckel2022-11-211-3/+3
|
* cmNinjaNormalTargetGenerator: fix grammar in verbose commentBen Boeckel2022-11-211-1/+1
|
* Ninja: Avoid re-linking a Swift executable on every buildEvan Wilde2022-11-171-1/+3
| | | | | | Swift doesn't emit swiftmodules for executables, so we shouldn't put it in dependency graph. Ninja sees the "missing" dependency and always tries to rebuild/re-link the target.
* Swift: Omit output-file-map when used as a linkerEvan Wilde2022-10-281-7/+1
| | | | | | | | | | | | | | | Swift is used as the linker for non-swift files because it needs to pull files like swiftrt.o in when swift symbols are present to ensure that the swift runtime is linked. The swift driver uses clang as the underlying linker, which pulls in crtbegin.o and friends when appropriate, so using Swift as a linker for C/C++ libraries is fine. The output-file-map was getting passed to all Swift invocations, regardless of whether or not we generated one. This patch changes it so that we only include the output-file-map in the Swift compiler invocation if we have actually generated the file.
* Ninja: Fix mixed Swift/CXX library target generationEvan Wilde2022-09-161-7/+14
| | | | | | | | | | | | | | | | With how things were before, mixed Swift/C++ libraries would result in a broken ninja file. `cpp.cpp.o` was emitted by the compiler, but was also being included in the `linkBuild.Outputs` list, so it was being emitted by multiple targets. The fix checks that the source language is Swift before adding it to the list of additional outputs. If it is Swift, this isn't a problem. If it isn't Swift, we don't include it in the list of outputs. On the other side, the C++ file was also being passed as a source file, which the Swift compiler can't compile. So we add the C++ object file as an explicit dependency and the object file is then added to the list of Swift sources.
* remove unused variableRobert Maynard2022-07-131-1/+0
|
* Ninja: Avoid duplicating /DEF: linker flag with MSVC toolsBrad King2022-05-311-3/+0
| | | | | | | | | | In commit 9a0d5a828a (Ninja: add /DEF: flag to linker call, 2012-03-10, v2.8.8~22^2~7) the logic should have been added to `GetTargetFlags` in place of the older logic in that method from commit 7cef36c628 (ENH: add the ability to generate custom commands for a language that is not supported by an IDE, 2004-10-21, v2.4.0~2655). Fixes: #23570
* cmLocalGenerator: Adopt AppendModuleDefinitionFlag methodBrad King2022-05-311-2/+2
| | | | Migrate from `cmCommonTargetGenerator::AddModuleDefinitionFlag`.
* Provide guidance when trying to use non-enabled languageRobert Maynard2022-05-041-7/+3
| | | | Fixes #23463
* CUDA: Support CMP0105 on ClangRaul Tambre2021-11-081-0/+15
| | | | | | | Add link flags during the "device compile" step. Enabled the relevant tests. The disable reasons regarding separable compilation were outdated and the actual failure case was device link flags support.
* CUDA: Use local shorthands for variables in Clang device link codeRaul Tambre2021-11-071-12/+10
| | | | Helps reduce wrapping of lines making code more readable.
* CUDA: Avoid unnecessary allocation and GetLinkLanguage()Raul Tambre2021-11-071-10/+8
| | | | | There's no reason to allocate the cmNinjaLinkLineDeviceComputer on the heap. We can also assume the link language as CUDA in cmLocalGenerator::GetDeviceLinkFlags().
* CUDA: Ignore USE_WATCOM_QUOTE for device link rulesRaul Tambre2021-11-071-3/+0
| | | | It's useless as the Watcom compiler isn't supported by NVCC.
* Ninja: Fix creation of Windows import library directoryBrad King2021-11-031-2/+2
| | | | | | | Call `EnsureParentDirectoryExists` with our internal representation of the path, not the representation quoted/encoded for Ninja. Fixes: #22841
* Rename cmProp in cmValueMarc Chevrier2021-09-211-13/+13
|
* Merge topic 'cuda_separable_clang_make'Brad King2021-07-291-5/+5
|\ | | | | | | | | | | | | | | 3975678fcc CUDA/Clang: Simplify --register-link-binaries logic 0b1cea66cd CUDA/Clang: Fix separable compilation in non-root directories with Makefiles Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6400
| * CUDA/Clang: Simplify --register-link-binaries logicroot2021-07-291-5/+5
| | | | | | | | | | | | | | Move the logic for appending cubin afterwards, so the check can simply be empty(). With the Makefile generator the option is now at the front instead of being intermixed with the actual bins.
* | LINK_WHAT_YOU_USE feature: externalize configurationMarc Chevrier2021-07-091-14/+22
|/ | | | | | | | Currently, this feature is only supported on ELF platforms. So, the property LINK_WHAT_YOU_USE will be ignored for other plateforms. Moreover, flags and commands are now controled by CMake variables. Fixes: #20174
* Ninja: Fix LINK_WHAT_YOU_USE link flag placementĐoàn Trần Công Danh2021-06-251-6/+3
| | | | | | | Move `-Wl,--no-as-needed` from the `<FLAGS>` placeholder to `<LINK_FLAGS>`, as it is in the Makefile generators. Fixes: #22342
* Launchers: Support setting linker launchersBobby D Reynolds2021-05-281-0/+5
| | | | Fixes: #18316
* cmNinjaNormalTargetGenerator: Fix "Language" rule variableBobby D Reynolds2021-05-281-1/+1
| | | | Fixes: commit 3bc63e99e4 (Refactor: Prepare Ninja generator for multi-config, 2019-11-14, v3.17.0-rc1~290^2~3)
* cmNinjaNormalTargetGenerator: Factor out build event byproduct collectionBrad King2021-05-251-9/+10
| | | | | This was left out of commit 68e5f92cad (cmGlobalNinjaGenerator: Factor out custom command output collection, 2021-05-18).
* cmNinjaTargetGenerator: Rename source file path lookup method for clarityBrad King2021-05-251-3/+5
| | | | | | The `GetSourceFilePath` method is meant only for compiled sources, and automatically handles converting it to a path for the Ninja build manifest. Rename the method to clarify both.
* Ninja/Swift: Remove redundant calls to ConvertToNinjaPathBrad King2021-05-251-5/+3
| | | | `GetSourceFilePath` already handles converting to a Ninja path.
* Merge topic 'ninja-multi-long-command-line-config'Brad King2021-05-031-11/+19
|\ | | | | | | | | | | | | ad08f93ee4 Ninja Multi-Config: Split long command lines by config Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !6067
| * Ninja Multi-Config: Split long command lines by configKyle Edwards2021-04-301-11/+19
| | | | | | | | Fixes: #22123
* | Ninja: Escape SONAME on linker command lineAlexander Stein2021-03-041-2/+4
|/ | | | | | | | | | | If the shared object name contains spaces, they need to be properly escaped, or link command will fail. This was already done for soname symlink creation in commit 13c92b4a30 (Ninja: Fix creation of library symlinks in folders with spaces, 2019-05-20, v3.15.0-rc1~87^2). Fixes: #20331
* Ninja Multi-Config: Run POST_BUILD when BYPRODUCTS don't overlapKyle Edwards2021-01-071-8/+12
| | | | Fixes: #21252
* Code style: add missed explicit 'this->'Oleksandr Koval2021-01-051-29/+31
| | | | | CMake uses explicit 'this->' style. Using custom clang-tidy check we can detect and fix places where 'this->' was missed.
* cmLocalGenerator::GetRuleLauncher: return cmPropvvs314152020-11-021-4/+4
|
* CUDA: Clang separable compilationRaul Tambre2020-09-241-24/+200
| | | | | | | | | | | | 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-1/+6
|
* cmMakefile::GetDefinition: return cmPropVitaly Stakhovsky2020-09-021-11/+11
|
* Merge topic 'ninja-multi-rsp-remove-path'Brad King2020-08-061-10/+2
|\ | | | | | | | | | | | | | | cdb50af2f6 Ninja: Restore shorter path to response files Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: alcroito <alexandru.croitor@qt.io> Merge-request: !5094
| * Ninja: Restore shorter path to response filesKyle Edwards2020-08-031-10/+2
| | | | | | | | | | | | | | | | | | | | | | | | In commit 99ed39b011 (Ninja Multi-Config: Make link response files per-config, 2020-07-15, v3.17.4~3^2), we added the target directory to the response file under the mistaken assumption that two different targets with the same name could be in different directories. However, this causes the path to the response file to be too long to fit on a command line. Take the path back out, while leaving in the per-config split. Fixes: #21050
* | Source: use cmNonempty()Vitaly Stakhovsky2020-07-281-1/+1
| |
* | Ninja: Remove parameter default for cmNinjaTargetDependsKyle Edwards2020-07-241-3/+4
| |
generated by cgit v0.12 at 2025-01-19 13:30:03 (GMT)