| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
Include the name of the `EXPORT` in the filename when generating export
information for C++ modules. This allows the same directory to be used
for multiple sets of C++ module-using targets.
For `export(TARGETS)` uses, generate a name based on the hash of the
concatenation of the target names involved with the `export()` call.
Fixes: #25609
|
|
|
|
|
|
|
|
|
| |
Compute link information for all C++ targets which support
modules instead of just those which may provide modules, as
they may import modules as well. This captures `OBJECT` libraries using modules
which otherwise do not have link steps.
Fixes: #25592
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| | |
405dc7d19c Tests/CXXModules/scan_properties: use `ixx` extension
029ddc3410 cmVisualStudio10TargetGenerator: always specify scanning
6c9614cbf4 Tests/CXXModules: add a test case for VS generation without flags
34f4423851 cmVisualStudio10TargetGenerator: fix typo in flag name
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9104
|
| |
| |
| |
| | |
This ensures that Visual Studio is told not to scan this explicitly.
|
| |
| |
| |
| |
| |
| |
| | |
Previously, the `ScanSourceForModuleDependencies` flag was not added to
the VS project if "nothing" prompted custom flags.
See: #25519
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
63bbb3768d cmLocalGenerator: ignore scanned sources for unity builds
76b5383123 cmGlobalGenerator: add unity sources after computing target compile features
7fc2a83fe6 Tests/CXXModules: add a test with unity build support
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9118
|
| |/
| |
| |
| |
| | |
C++ module-using TUs cannot participate in unity builds. Add a test case
for this situation.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit cfd8a5ac1f (Makefiles: Add support of DEPFILE for
add_custom_command, 2020-12-04, v3.20.0-rc1~237^2~1) we added a
`ConvertToOutputPath` call on a path given to the `depends` field of
`WriteMakeRule`. The latter already handles escaping for Makefile
syntax.
Fixes: #25554
|
|/
|
|
| |
Fixes: #25541
|
|
|
|
| |
Fixes: #25513
|
|
|
|
|
|
|
|
|
|
|
| |
In commit 878ae03832 (macOS: IMPORTED framework: Honor SYSTEM target
property in all cases, 2023-08-27, v3.28.0-rc1~162^2) we broke support
for `IMPORTED_LOCATION_<CONFIG>` without `IMPORTED_CONFIGURATIONS`.
Previously it worked if the importing project's configurations match the
set of `IMPORTED_LOCATION_<CONFIG>` properties set. Fix that case.
Fixes: #25506
Issue: #25515
|
|
|
|
| |
When we know that the cupti library exists explicitly request the CUDA Toolkit test to verify the existence
|
|\
| |
| |
| |
| |
| |
| | |
8f53526dec Tests: Do not expect EINTR when sleep is interrupted on GNU/Hurd
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9052
|
| |
| |
| |
| |
| |
| | |
Previously `RunCMake.CTestTimeout` failed on GNU/Hurd because the
`sleep` command does not set `errno` to `EINTR` when interrupted by a
signal, which is a Linux-specific feature.
|
|/
|
|
|
|
|
|
|
| |
Account for:
* commit `8f47d5aa33` (Remove `-w dupbuild` completely, always error
on duplicate edges, 2023-11-29)
* commit `4d98903d4c` (Improve misleading error message when an output
is defined multiple times, 2023-12-06)
|
|\
| |
| |
| |
| |
| |
| |
| | |
e63983956d Tests/CXXModules: enhance `internal-partitions` test
8a658fb9ec Tests/CXXModules: import from an internal partition
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9039
|
| |
| |
| |
| |
| |
| | |
This test previously did not *require* that the internal partition be
specified as a transitive usage because nothing from it was exposed.
Plumb through usages such that the internal partitions are required.
|
| |
| |
| |
| |
| |
| | |
It is reported that MSVC doesn't support the `modname=` syntax in its
`-reference modname=modname.ifc` for internal partitions. Add a test
case.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
e9b0dcbbfa cmCxxModuleMapper: Fix transitive requirements computation
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !9030
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously CMake may generate incomplete transitive requirements in
CMakeFiles/<target>.dir/CXXModules.json and therefore in module mapper
for compiler, when source files were listed in CMakeList.txt in a
certain order.
This commit fixes the problem by correctly tracking unfinished
transitive requirements computation of module units.
There have been a simple circular test case whose circular dependency
was reported by build system. Now with this correct implementation it's
reported by CMake generating module mappers.
Add two test cases for transitive requirements computation, one with
adding source files in hardcoded order, and the other in randomized
order.
Fixes: #25465
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
ef49ed0fe1 LLVMFlang: Fix MSVC ABI debug information format options
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !9037
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In commit 26bf32cdc6 (LLVMFlang: Add support for targeting MSVC ABI on
Windows, 2023-09-28, v3.28.0-rc1~10^2) we incorrectly recorded `-g` as
supporting the `ProgramDatabase` format, but it is actually `Embedded`,
matching Clang.
In order to support easy integration with C and C++ projects that use
the `.pdb` debug formats, pretend LLVMFlang supports them and just don't
actually emit any debug information.
Issue: #24840
|
|/
|
|
| |
This tests that PCH usage works with scanning logic.
|
|
|
|
| |
Issue: #25450
|
|\
| |
| |
| |
| |
| |
| |
| | |
cbd549b09e cxxmodules: Add more suggestions to no-modules-support diagnostics
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !9011
|
| |
| |
| |
| |
| |
| | |
Tell users what generators *do* support C++ modules. Report the current
generator to make clear it is not one of those supporting modules.
Also clarify the purpose of the existing documentation references.
|
|/
|
|
|
|
|
| |
Fix commit e40d2cb3af (Xcode: Add embed resources support, 2023-07-31,
v3.28.0-rc1~281^2). The implementation should not name the `_PATH`
suffix explicitly. That variant is automatically handled by
`cmGlobalXCodeGenerator::AddEmbeddedObjects`.
|
|\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
beb1393f8f Merge branch 'revert-exact-collation-depends-3.27' into fortran-objects-as-sources-fix
a033dce326 Makefiles: provide, but do not consume, "forward linked" target dirs
7cd0adab1b cmCommonTargetGenerator: use modules from linked object-referenced targets
1175f1c874 LinkItem: track `cmSourceFile` instances for external objects
d2fa56772f Ninja: support "forwarding" modules from other targets
ec1e589bec Ninja: Revert exact collation dependencies for 3.27
06df59b930 cmCommonTargetGenerator: return forward linked target dirs too
f8729ab366 cmLocalUnixMakefileGenerator3: handle object-referencing Fortran modules
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Merge-request: !8989
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When a target uses objects from another target which provides modules as
sources, the modules provided by the referenced target must also be
treated as if they were provided by the referencing target. Add the
concept of "forwarding" modules so that consumers can use modules
created by these sources as well.
Note that this is only sensible for Fortran where module usages are
implicit as far as CMake's visibility model is concerned. C++ modules
have their own concept of visibility which does not require or support
such `$<TARGET_OBJECTS>` reuse in this way.
|
| |\
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
fortran-objects-as-sources-fix
* 'revert-exact-collation-depends-3.27' (early part):
Tests/FortranModules: add test for TARGET_OBJECTS-as-linked-items module usage
Tests/FortranModules: add test for TARGET_OBJECTS-as-sources module usage
|
| | |
| | |
| | |
| | |
| | |
| | | |
Test module usage across a `$<TARGET_OBJECTS>`-as-linked-items use case.
See: #25425
|
| | |
| | |
| | |
| | |
| | |
| | | |
Test module usage across a `$<TARGET_OBJECTS>`-as-sources use case.
See: #25425
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
77a7edb73f Clang-CXX: copy into the dyndep output on success
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: Namniav W <namniav@gmail.com>
Merge-request: !8991
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When `clang-scan-deps` fails to scan (e.g., bad source syntax, junk
flags, etc.), the redirection unconditionally updates the file. If this
fails, the `.ddi` file timestamp is updated. If the state is then
reverted (e.g., the command line returns to the state of the last
successful build), the updated file is not useful, but `ninja` does not
rerun because:
- the command hash matches the last successful run
- the output file is newer than its inputs
However, since the `.ddi` file has been updated with bogus contents from
a failed scan, collation fails as the `rules` array is empty (or
incomplete from a batch scan).
If `clang-scan-deps` were properly aware of its output file, it could
use this to not write the file if any inner scan fails. Requested in
https://github.com/llvm/llvm-project/issues/72875.
See: https://github.com/llvm/llvm-project/issues/72875
Fixes: #25429
|
|\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
a3a85524cd fileapi: Fix file sets' base directories relative to top source
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Reviewed-by: Ben Boeckel <ben.boeckel@kitware.com>
Merge-request: !8977
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This field was added by commit b3e9fb67bb (file-api: support exporting
file set information, 2022-11-03, v3.26.0-rc1~389^2) but the relative
path convention used elsewhere was accidentally left out.
Fixes: #25422
|
| | | |
|
| | | |
|
|\ \ \
| | |/
| |/| |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since commit b6a5382217 (Ninja: depend on language module information
files directly, 2023-02-10, v3.27.0-rc1~502^2), the return value of
`cmCommonTargetGenerator::GetLinkedTargetDirectories` must account for
linked object libraries because they may provide modules (#25112).
These were added by commit b665966933 (cmComputeLinkInformation: track
OBJECT library dependencies, 2023-07-22, v3.27.1~5^2). However, targets
named by `$<TARGET_OBJECTS:...>` sources are also needed (#25365).
The latter were added by commit 22da18b995 (Fortran: Restore support for
TARGET_OBJECTS providing modules, 2023-10-27, v3.28.0-rc4~9^2) and
commit 035302b7e3 (cmComputeLinkDepends: also copy the target from
object link items, 2023-10-27, v3.28.0-rc4~9^2~2). However, their
approach added link entries not actually specified by projects. It also
incorrectly re-used `cmComputeLinkDepends::AddLinkObject` for object
library targets when it is meant for their individual object files.
These problems caused additional regressions (#25417). Revert the
implementation parts of those commits and leave behind an assertion and
comment to help avoid the mistake in the future. Instead, track targets
named by `$<TARGET_OBJECTS:...>` sources with a dedicated member.
Issue: #25112
Issue: #25365
Fixes: #25417
Co-authored-by: Ben Boeckel <ben.boeckel@kitware.com>
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fix logic added by commit 634079b86d (cmGeneratorExpressionEvaluator:
Short-circuit boolean operators, 2023-09-11, v3.28.0-rc1~47^2) and
add missing test cases.
Fixes: #25412
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
a0fabc4769 cmGlobalGeneratorFactory: Provide complete cmGlobalGenerator to deleter
85627a93c9 cmCTestBuildCommand: Avoid requiring complete cmGlobalGenerator type publicly
641c02a3ce cmList: Avoid using operator-> on input iterator
e4483b8871 Tests: Avoid compiling call to dap::optional<dap::string>(nullptr)
Acked-by: Kitware Robot <kwrobot@kitware.com>
Acked-by: buildbot <buildbot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !8950
|
| | | | |
|
|/ / /
| | |
| | |
| | | |
Issue: #21752
|
| | |
| | |
| | |
| | | |
Fixes: #25383
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
release-3.28
1f507580a1 cmGlobalGenerator: give context about module queries
889aa0354a CMP0155: ignore scanning for sources if no scanner is available
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !8925
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This allows for a more graceful transition for projects using C++20
without scanner support (e.g., Clang 15 or GCC 13). While newer
compilers will (needlessly) scan, it allows C++20-using projects to use
older compilers without having to set `CMAKE_CXX_SCAN_FOR_MODULES` to
support newer CMake minimum versions.
Fixes: #25357
|
|\ \ \ \
| | |/ /
| |/| |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
22da18b995 Fortran: Restore support for TARGET_OBJECTS providing modules
64d9240564 cmComputeLinkInformation: skip over linking to items for object purposes
035302b7e3 cmComputeLinkDepends: also copy the target from object link items
861876b936 Tests/ObjectLibrary: fix comment
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Acked-by: scivision <michael@scivision.dev>
Merge-request: !8923
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Continue b665966933 (cmComputeLinkInformation: track OBJECT library
dependencies, 2023-07-22) which added explicitly listed `OBJECT`
libraries to the list of targets which the collator needs to consider.
Now also consider targets which provide objects directly to the target
via a `$<TARGET_OBJECT>` source lists.
Also add tests which use target objects directly and through an
`INTERFACE` library with target objects in its own sources.
Fixes: #25365
|
| | | | |
|