summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
* Merge topic 'RH-gcc-toolset-10-bug-check' into release-3.28Brad King2023-12-051-0/+28
|\ | | | | | | | | | | | | | | 40af103402 cmCMakePath: do not use std::filesystem::path with RH gcc-toolset-10 Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: buildbot <buildbot@kitware.com> Merge-request: !9026
| * cmCMakePath: do not use std::filesystem::path with RH gcc-toolset-10Marc Chevrier2023-12-041-0/+28
| | | | | | | | Fixes: #25458, #25453
* | Merge topic 'cxxmodules-pch' into release-3.28Brad King2023-12-056-8/+34
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | 40dc13b242 cmNinjaTargetGenerator: PCH files do not need dyndep f61c64cd1c cmLocalGenerator: prevent scanning of PCH source files ea8c37b759 Tests/CXXModules: add a test which scans a PCH-using source Acked-by: Kitware Robot <kwrobot@kitware.com> Tested-by: buildbot <buildbot@kitware.com> Merge-request: !9032
| * | cmNinjaTargetGenerator: PCH files do not need dyndepBen Boeckel2023-12-041-8/+7
| | | | | | | | | | | | Fixes: #24209
| * | cmLocalGenerator: prevent scanning of PCH source filesBen Boeckel2023-12-041-0/+3
| | |
| * | Tests/CXXModules: add a test which scans a PCH-using sourceBen Boeckel2023-12-044-0/+24
| | | | | | | | | | | | This tests that PCH usage works with scanning logic.
* | | Merge topic 'cmFileCopier-error-loss' into release-3.28Brad King2023-12-057-59/+77
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | a820877d03 errors: avoid constructing a stream before getting the last error 5cf7018af6 cmFileCopier: remember error statuses and get their strings 0639a32d3a cmFileTimes: return status codes from APIs Acked-by: Kitware Robot <kwrobot@kitware.com> Tested-by: buildbot <buildbot@kitware.com> Merge-request: !9023
| * | | errors: avoid constructing a stream before getting the last errorBen Boeckel2023-12-025-28/+20
| | | | | | | | | | | | | | | | | | | | Constructing a stream may involve operations that change the global error state. Avoid the streams by using `cmStrCat` instead.
| * | | cmFileCopier: remember error statuses and get their stringsBen Boeckel2023-12-021-14/+23
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The last error may have changed between the original call and the `GetLastSystemError()` call. Remember the status explicitly and ask it for its error string. Reported on Discourse: https://discourse.cmake.org/t/9539
| * | | cmFileTimes: return status codes from APIsBen Boeckel2023-12-022-17/+34
| | | | | | | | | | | | | | | | | | | | This avoids accidentally overwriting the global error state before fetching the intended error code.
* | | | Merge topic 'fix-include-windows' into release-3.28Brad King2023-12-051-1/+1
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 696e14d977 cmFileLockResult: Fix inclusion of windows.h when cross-compiling Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9035
| * | | | cmFileLockResult: Fix inclusion of windows.h when cross-compilingBrad King2023-12-041-1/+1
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In commit 64821d8a26 (cmFileLockResult: Remove expensive windows.h include, 2023-06-16, v3.28.0-rc1~446^2~13) we accidentally capitalized the name of the header. This matters when cross-compiling from a host with a case-sensitive filesystem. Fixes: #25474
* | | | Merge topic 'execute_process-no-extension' into release-3.28Brad King2023-12-051-13/+30
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | fc6231bee5 libuv: win/spawn: run executables with no file extension b37d9378de libuv: Revert "win/spawn: run executables with no file extension" Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Kyle Edwards <kyle.edwards@kitware.com> Merge-request: !9033
| * | | libuv: win/spawn: run executables with no file extensionKyle Edwards2023-12-041-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport this commit from libuv PR 4241 to restore `execute_process()` support for running executables on Windows with no file extension. Fixes: #25450
| * | | libuv: Revert "win/spawn: run executables with no file extension"Brad King2023-12-041-12/+25
| |\ \ \ |/ / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This reverts commit da9df7425a (libuv: win/spawn: run executables with no file extension, 2023-11-29, v3.28.0-rc6~1^2~1). It incorrectly searched the `PATH` for extension-less command names. Another fix will be needed for the regression motivating it. Record this as a merge from the last-imported upstream libuv snapshot branch so that future `git blame` points to the upstream for the original code instead of this commit. Fixes: #25473 Issue: #25450
* | | | Merge topic 'libuv-win-no-default-current-directory' into release-3.28Brad King2023-12-041-4/+6
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | ab561b86fb libuv: win: honor NoDefaultCurrentDirectoryInExePath env var Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9022
| * | | libuv: win: honor NoDefaultCurrentDirectoryInExePath env varKyle Edwards2023-12-011-4/+6
|/ / / | | | | | | | | | | | | Backport commit 5e302730cd (win: honor NoDefaultCurrentDirectoryInExePath env var, 2023-12-01) from libuv PR 4238.
* | | CMake 3.28.0-rc6v3.28.0-rc6Brad King2023-11-301-1/+1
| | |
* | | Merge topic 'execute_process-no-extension' into release-3.28Brad King2023-11-308-25/+69
|\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | f6d2efa752 Tests: Add case to cover execute_process support for no extension on Windows da9df7425a 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
| * | | Tests: Add case to cover execute_process support for no extension on WindowsKyle Edwards2023-11-307-0/+57
| | | | | | | | | | | | | | | | Issue: #25450
| * | | libuv: win/spawn: run executables with no file extensionKyle Edwards2023-11-301-25/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Backport this commit from libuv PR 4241 to restore `execute_process()` support for running executables on Windows with no file extension. Fixes: #25450
* | | | Merge topic 'rpm-quoting' into release-3.28Brad King2023-11-302-14/+19
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 5123e9e160 ci: unmask RPM tests on Fedora 39 bf22ac5263 CPack/RPM: Quote paths in rpm spec only if they have whitespace 75ea6207b7 CPack/RPM: Factor out helper to quote paths in generated rpm spec Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9005
| * | | | ci: unmask RPM tests on Fedora 39Ben Boeckel2023-11-291-9/+0
| | | | |
| * | | | CPack/RPM: Quote paths in rpm spec only if they have whitespaceBrad King2023-11-291-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | CPack/RPM: Factor out helper to quote paths in generated rpm specBrad King2023-11-291-5/+14
| | | | |
* | | | | Merge topic 'ccmake-install-rds-crash' into release-3.28Brad King2023-11-301-0/+2
|\ \ \ \ \ | |_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | d01120a47a cmGlobalGenerator: clear RuntimeDependencySet members at configure Acked-by: Kitware Robot <kwrobot@kitware.com> Merge-request: !9013
| * | | | cmGlobalGenerator: clear RuntimeDependencySet members at configureBen Boeckel2023-11-291-0/+2
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f2617cf8e6 (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
* | | | Merge topic 'cxxmodules-diagnostics' into release-3.28Brad King2023-11-296-21/+61
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | cxxmodules: Add more suggestions to no-modules-support diagnosticsBrad King2023-11-286-21/+61
| |/ / / | | | | | | | | | | | | | | | | | | | | 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.
* | | | Merge topic 'xcode-embed-resources' into release-3.28Brad King2023-11-293-5/+4
|\ \ \ \ | |/ / / |/| | | | | | | | | | | | | | | | | | | | | | | 6030df205a Xcode: Fix embed resources prop name Acked-by: Kitware Robot <kwrobot@kitware.com> Acked-by: Deal <halx99@live.com> Merge-request: !9008
| * | | Xcode: Fix embed resources prop namehalx992023-11-283-5/+4
|/ / / | | | | | | | | | | | | | | | | | | 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`.
* | | Merge branch 'release-3.27' into release-3.28Brad King2023-11-281-0/+20
|\ \ \
| * | | CMake 3.27.9v3.27.9Brad King2023-11-282-1/+21
| | | |
* | | | Merge branch 'release-3.27' into release-3.28Brad King2023-11-272-4/+14
|\ \ \ \ | |/ / /
| * | | Merge branch 'release-3.26' into release-3.27Brad King2023-11-272-4/+14
| |\ \ \
| | * | | CMake 3.26.6v3.26.6Brad King2023-11-273-5/+15
| | | | |
* | | | | Merge branch 'release-3.27' into release-3.28Brad King2023-11-270-0/+0
|\ \ \ \ \ | |/ / / /
| * | | | Merge branch 'revert-exact-collation-depends-3.27' into release-3.27Brad King2023-11-2718-9/+143
| |\ \ \ \ | | | | | | | | | | | | | | | | | | Merge-request: !8996
* | \ \ \ \ Merge topic 'fortran-objects-as-sources-fix' into release-3.28Brad King2023-11-2739-78/+419
|\ \ \ \ \ \ | |_|_|_|/ / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
| * | | | | Merge branch 'revert-exact-collation-depends-3.27' into ↵Ben Boeckel2023-11-230-0/+0
| |\ \ \ \ \ | | | |/ / / | | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | fortran-objects-as-sources-fix * revert-exact-collation-depends-3.27: Fortran: Revert exact collation dependencies for 3.27
| | * | | | Ninja: Revert exact collation dependencies for 3.27Ben Boeckel2023-11-211-9/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Revert commit b6a5382217 (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
| * | | | | Makefiles: provide, but do not consume, "forward linked" target dirsBen Boeckel2023-11-232-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | cmCommonTargetGenerator: use modules from linked object-referenced targetsBen Boeckel2023-11-232-1/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | LinkItem: track `cmSourceFile` instances for external objectsBen Boeckel2023-11-236-13/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Ninja: support "forwarding" modules from other targetsBen Boeckel2023-11-239-1/+74
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | cmCommonTargetGenerator: return forward linked target dirs tooBen Boeckel2023-11-214-38/+62
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will be used for module forwarding in order to support `$<TARGET_OBJECTS>` usage in source and link libraries calls.
| * | | | | cmLocalUnixMakefileGenerator3: handle object-referencing Fortran modulesBen Boeckel2023-11-211-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | cmNinjaTargetGenerator: handle object-referencing Fortran modulesBen Boeckel2023-11-211-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | cmGeneratorTarget: also check included objects for Fortran modulesBen Boeckel2023-11-211-9/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fortran modules provided by objects in `$<TARGET_OBJECTS>` should also count as "has Fortran modules" for the target referencing the objects.
| * | | | | cmCommonTargetGenerator: use modules from object-referenced targetsBen Boeckel2023-11-211-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v0.12 at 2024-12-28 16:51:26 (GMT)