- Nov 30, 2023
-
-
Brad King authored
-
f6d2efa7 Tests: Add case to cover execute_process support for no extension on Windows da9df742 libuv: win/spawn: run executables with no file extension Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: scivision <michael@scivision.dev> Merge-request: !9017
-
Kyle Edwards authored
Issue: #25450
-
Kyle Edwards authored
Backport this commit from libuv PR 4241 to restore `execute_process()` support for running executables on Windows with no file extension. Fixes: #25450
-
5123e9e1 ci: unmask RPM tests on Fedora 39 bf22ac52 CPack/RPM: Quote paths in rpm spec only if they have whitespace 75ea6207 CPack/RPM: Factor out helper to quote paths in generated rpm spec Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9005
-
d01120a4 cmGlobalGenerator: clear RuntimeDependencySet members at configure Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9013
-
- Nov 29, 2023
-
-
-
Brad King authored
RPM supports either whitespace with quoting or globbing without quoting. Prior to RPM 4.19 it accepted globbing in quotes, but it only globbed correctly without whitespace, where quoting was not necessary anyway. Starting in RPM 4.19, glob characters in quotes are considered literal. Fixes: #25421 Inspired-by: Ben Boeckel <ben.boeckel@kitware.com> See: https://github.com/rpm-software-management/rpm/commit/d44114f007f54f205ffa13d22724199fe50a137a
-
Brad King authored
-
Ben Boeckel authored
Commit f2617cf8 (Source: Add cmInstallRuntimeDependencySet, 2021-05-19) introduced via !6186 to 3.21 added storage to the global generator for runtime dependency sets. However, this was not cleared at the start of configure in the `ClearGeneratorMembers()` method. When using `ccmake` to configure (and, presumably `cmake-gui` too), projects using `install(TARGETS … RUNTIME_DEPENDENCY_SET)` would use dependency set tracking instances from previous configure runs that held references to targets free'd with the `cmMakefile` instance that held them. Clear the dependency sets at the beginning of configure so that they are not remembered and trigger via use-after-free bugs when used. Fixes: #25446
-
cbd549b0 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
-
6030df20 Xcode: Fix embed resources prop name Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Deal <halx99@live.com> Merge-request: !9008
-
- Nov 28, 2023
- Nov 27, 2023
-
-
Brad King authored
-
Brad King authored
-
Brad King authored
-
Brad King authored
Merge-request: !8996
-
beb1393f Merge branch 'revert-exact-collation-depends-3.27' into fortran-objects-as-sources-fix a033dce3 Makefiles: provide, but do not consume, "forward linked" target dirs 7cd0adab cmCommonTargetGenerator: use modules from linked object-referenced targets 1175f1c8 LinkItem: track `cmSourceFile` instances for external objects d2fa5677 Ninja: support "forwarding" modules from other targets ec1e589b Ninja: Revert exact collation dependencies for 3.27 06df59b9 cmCommonTargetGenerator: return forward linked target dirs too f8729ab3 cmLocalUnixMakefileGenerator3: handle object-referencing Fortran modules ... Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: buildbot <buildbot@kitware.com> Merge-request: !8989
-
- Nov 23, 2023
-
-
* revert-exact-collation-depends-3.27: Fortran: Revert exact collation dependencies for 3.27
-
Makefiles do not have a per-object sense of where they come from, so forwarding any module information here would end up with incorrect module file path construction by consuming targets. Leave a TODO item in its place.
-
Fortran modules provided by objects added as linked items via `$<TARGET_OBJECTS>` should also be considered as "linked targets" for collation purposes. As C++ modules have their own visibility rules through their `FILE_SET` feature, do not expose these for C++ module collation.
-
The target may be required in order to provide Fortran modules, so track the source file so that the target may be looked up when needed.
-
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.
-
- Nov 22, 2023
-
-
Brad King authored
-
Brad King authored
-
486c89dd Help: Fix ctest(1) manual links to www.cdash.org Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !8998
-
77a7edb7 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
-
- Nov 21, 2023
-
-
Brad King authored
Merge-request: !8998
-
Brad King authored
Merge-request: !8998
-
Brad King authored
When the link was updated to `https` by commit 52eac457 (Help: Fix link to cdash.org from CTest manual, 2021-04-21, v3.21.0-rc1~262^2~2) the markup was incorrectly adjusted to show the link as part of the "See Also" section. It is meant to be the link destination for links in prose elsewhere in the manual. Fix the markup and move it to a clearer location. Also update the link to resolve a redirect.
-
Revert commit b6a53822 (Ninja: depend on language module information files directly, 2023-02-10, v3.27.0-rc1~502^2) from !8197. This reverts the "exact dependencies" for collation inputs and returns to "get all targets" and target-ordering. Use of exact dependencies caused a parade of use cases that had not been tested previously to be found and need fixing over the 3.27 release series. To stop the flow on 3.27, revert to the 3.26 strategy. We will continue in 3.28. Note that this is a restoration of 3.26 semantics where incremental rebuilds may be subtly incorrect in the presence of stale `<LANG>Modules.json` files. However, since C++ support is experimental and Fortran has always had this problem as of 3.27, it is not considered a regression. See: #25112 See: #25123 See: #25252 See: #25365 See: #25417 See: #25425
-
Ben Boeckel authored
This will be used for module forwarding in order to support `$<TARGET_OBJECTS>` usage in source and link libraries calls.
-
Ben Boeckel authored
Targets only using Fortran modules via `$<TARGET_OBJECTS>` also need a collation step to be performed. Check for this case and trigger the depends rule to be used.
-
Ben Boeckel authored
Targets only using Fortran modules via `$<TARGET_OBJECTS>` also need a collation step to be performed. Check for this case and trigger the collation rule to be added and used.
-
Ben Boeckel authored
Fortran modules provided by objects in `$<TARGET_OBJECTS>` should also count as "has Fortran modules" for the target referencing the objects.
-
Ben Boeckel authored
Fortran modules provided by objects added as sources via `$<TARGET_OBJECTS>` should also be considered as "linked targets" for collation purposes. As C++ modules have their own visibility rules through their `FILE_SET` feature, do not expose these for C++ module collation.
-