summaryrefslogtreecommitdiffstats
path: root/Source/cmNinjaNormalTargetGenerator.cxx
Commit message (Collapse)AuthorAgeFilesLines
* Swift/Ninja: Add support for response filesEvan Wilde2024-01-081-2/+4
| | | | | | | Adding support for `CMAKE_NINJA_FORCE_RESPONSE_FILE` with Swift. Issue: #25490 Fixes: #25563
* Swift/Ninja: Split compilation modelEvan Wilde2023-12-151-7/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Splitting the Swift build into an object build and a separate link step, instead of building and linking in one step. The immediate benefit is LSP support because we are able to emit compile-commands for Swift files now. Additionally, it is possible to specify flags to the compile step, enabling folks to emit C and C++ headers from their Swift builds for C/C++ interop, without needing custom commands. Eventually, this gives us a path toward working object libraries. Object Libraries: - Object libraries don't work today because CMake doesn't emit targets for object libraries into the Ninja build file. - tl;dr: Object libraries work if they aren't WMO. Still need work to make WMO'd object libraries work. Object libraries still don't completely work with this patch because, while we emit the targets, the `TARGET_OBJECTS` generator expression expansion has a separate mechanism for determining what the names of the objects are based on the input source files, so targets that depend on an object library built with a whole-module optimization will depend on objects based on the name of the source file instead of the actual emitted object file. These features require being able to accurately model wholemodule builds though, because we actually need to track object files and WMO affects what objects are emitted. For that, we require CMP0157 use the NEW policy. When it's OLD, we have to fall back on the old behavior and cannot provide object libraries or the compile-commands for LSP. Issue: #25308
* Add options to specify linker toolMarc Chevrier2023-10-131-0/+8
| | | | | | | | | | | | | | | | | | Offer the capability, through variable `CMAKE_LINKER_TYPE`, as well as the target property `LINKER_TYPE` to specify which linker must be used. The implementation of this capability is specified by variables specific to the language and linker type: `CMAKE_<LANG>_USING_LINKER_<TYPE>`. Some definitions are provided as part of `CMake`. For example, to select the `LLVM` linker rather than the standard one, the type `LLD` should be specified through the variable `CMAKE_LINKER_TYPE`. And, on `Apple`, `Linux` and some environments on `Windows`, the variable `CMAKE_<LANG>_USING_LINKER_LLD` has value `-fuse-ld=lld`. And for `Windows` environments based on `MSVC`, where the linker is used directly, the tool `lld-link.exe` will be used rather than `link.exe`. Fixes: #19174, #24254, #24990
* Ninja: generate scanning and build rules for C++20 module synthetic targetsBen Boeckel2023-08-171-12/+85
|
* OPTIMIZE_DEPENDENCIES: Skip order-only deps for non-linking targetsCraig Scott2023-08-091-3/+5
| | | | Fixes: #21517
* IWYU: Update for Debian 12 CI jobBrad King2023-07-281-1/+0
| | | | | | `include-what-you-use` diagnostics, in practice, are specific to the environment's compiler and standard library. Update includes to satisfy IWYU for our CI job under Debian 12.
* LINK_OPTIONS: ensure correct dollar escapingMarc Chevrier2023-07-171-4/+0
| | | | | | Ensure correct escaping for Ninja and Makefile generators. Fixes: #25049
* 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
|
generated by cgit v0.12 at 2024-11-10 23:15:38 (GMT)