| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
These are kind of a mixed assortment.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
91a26ce041 cmComputeComponentGraph: use `size_t` for component indices
65c0a64dc5 cmComputeComponentGraph: use a name for "invalid component"
50abdaab93 IWYU: exclude `__decay_and_strip<int>` as well
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8128
|
| | | | |
| | | | |
| | | | |
| | | | | |
This avoids using casts everywhere when dealing with the sizes.
|
| | |/ /
| |/| |
| | | |
| | | | |
This is to prepare for making the graph use `size_t`.
|
| |_|/
|/| | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8443dfa946 curl: Work around missing OpenSSL symbol on machine with LCC 1.23
f9f5957884 Merge branch 'upstream-curl' into update-curl
dac458ddbf curl 2022-12-21 (c12fb3dd)
39dcf9469d curl: Update script to get curl 7.87.0
b2fe717a49 file: Avoid using deprecated curl progress callback
1cd38de47f ctest: Drop unnecessary use of deprecated CURLOPT_PUT
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8131
|
| | | | |
|
| | |/
| |/|
| | |
| | |
| | | |
All usage sites are already preceded by use of its replacement,
CURLOPT_UPLOAD.
|
| | | |
|
| | | |
|
| | | |
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
24bcad5bac VS: Honor compile options for ASM_NASM
b44714a642 VS: Honor compile options for ASM_MARMASM
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8125
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Ninja and Makefile generators honor `target_compile_options` and
friends for ASM_NASM `.asm` sources. Teach the VS generator to
honor them too for consistency.
Issue: #24289
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The Ninja and Makefile generators honor `target_compile_options` and
friends for ASM_MARMMASM `.asm` sources. Teach the VS generator to
honor them too for consistency.
Issue: #24289
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
a6bdf54a5e Watcom: Fix double-quote to be single-quote in response files for wlink
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8119
|
| |/ /
| | |
| | |
| | |
| | | |
Response files contained double-quote for any response file, but response files for wlink must contains single-quote. This is fix for libraries list response file. Problem for object file list was fixed by MR
!8115
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
01c1d81527 Xcode: Inherit Swift flags and compilation conditions
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8122
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Extend the change from commit dfaf55fbfd (Xcode: add extra
'$(inherited)' entries using InheritBuildSettingAttribute, 2021-05-03,
v3.21.0-rc1~182^2) to cover Swift flags and compilation conditions,
allowing CocoaPods and CMake to interoperate when used in the same
project.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
a1d065e5c7 Watcom: Replace WATCOMQUOTE format by UseWatcomQuote attribute
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8115
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | | |
Replace WATCOMQUOTE output format by UseWatcomQuote attribute to properly handle single quote
This attribute is used globaly only for Watcom linker to handle single-quote separator instead of double-quote
it doesn't mean different output format only change of quoting separator
It is now applied to any output form SHELL/RESPONSE/NINJAMULTI if Watcom linker is used otherwise double-quote is used
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
8024c41685 VS: Do not concurrently build custom commands with generated MAIN_DEPENDENCY
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8120
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Since commit 33c15ae2b9 (VS: Build custom commands concurrently when
possible, 2023-01-19) several tests have failed intermittently with the
VS generator. It seems that if the `BuildInParallel` setting is
attached to a generated input:
<CustomBuild Include="generated_input.txt">
<BuildInParallel Condition="...">true</BuildInParallel>
<Command Condition="...">copy geneated_input.txt output.txt</Command>
...
</CustomBuild>
then MSBuild does not wait for the input to be generated before running
the command.
This occurs when using `add_custom_command`'s `MAIN_DEPENDENCY`, so
avoid using `BuildInParallel` in that case.
Issue: #18405
|
| |_|/
|/| | |
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
1730d208b5 Add incremental Swift static lib build test
bf3a8ef6d5 Ninja: Swift: Add dependency edge to swiftmodule file
d0b469b7e0 Ninja: NFC: refactor swift module name computations
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8084
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| |/
|/| |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
8d4e510a44 Merge branch 'backport-cxxmodules-ninja-1.11' into cxxmodules-ninja-1.11
7abddcab08 Ninja: require Ninja 1.11 for C++ module support
0512428ad9 Ninja: require Ninja 1.11 for C++ module support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8099
|
| | |
| | |
| | |
| | |
| | | |
See: https://gitlab.kitware.com/cmake/cmake/-/issues/18355#note_1296721
See: https://github.com/ninja-build/ninja/pull/1937
|
|/ / |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
910ada1a88 Genex: $<CONFIG:> syntax of all entries checked
42e417ad12 GeneratorExpression Tests: Remove duplicate test entry
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8082
|
| | |
| | |
| | |
| | | |
Fixes #24327
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
33c15ae2b9 VS: Build custom commands concurrently when possible
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8093
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Enable the `BuildInParallel` setting in VS project files when supported.
Fixes: #18405
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
faa950a155 try_compile: Run native build tool with verbose output
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8095
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Make the compiler command lines visible in the configure log.
Issue: #23200
|
| | | | |
|
| | | | |
|
| |_|/
|/| | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
317aac14ef cmake: Stop pointing users at logs on configure errors
eae1398d09 cmake --system-information: Stop dumping CMake{Output,Error}.log
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8094
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since commit 18e1bfbb3c (cmake: On configure error suggest looking at
CMake*.log files, 2013-07-09, v2.8.12~210^2), when configuring a project
fails, we print `See also .../CMake{Output,Error}.log` near the end of
the output. This was intended to help users find failures in system and
compiler inspection checks, but for normal project errors the messages
may be misleading. The logs may contain incidental errors that are part
of normal operation and do not need to be addressed by the user.
Since commit f6ed2585e5 (Modules: Record system inspection steps in the
configure log, 2023-01-16), CMake's builtin modules no longer log
information to the old-style `CMake{Output,Error}.log` files anyway,
so stop mentioning them.
Fixes: #22131
Issue: #23200
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
4165eb3d0b Ninja: Emit swiftmodule from executable with exports
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !8048
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|