99d09ec45a VS: Suppress MSBuild default link flags not specified by project or user
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10891
MSBuild adds some `link` flags by default, but for CMake they may not
match what's produced by command-line generators. If these flags are
not specified by the project or user, suppress them.
Fixes: #27004
Extend commit 844d79916a (cmake --build: Add support for driving Xcode
workspaces, 2025-06-02) to support multiple `--target` arguments.
`xcodebuild -scheme` cannot be repeated in a single call, so call it
multiple times instead.
Issue: #26958
Co-Authored-By: Craig Scott <craig.scott@crascit.com>
When installing FILE_SETs, it is possible the FILE_SET has not yet been
created with target_sources(FILE_SET). Instead of ignoring this
situation, we need to track the installed FILE_SET names and their
possible install destinations.
At generation time we resolve the names and destinations concretely. If
a FILE_SET wasn't provided or isn't an INTERFACE, we silently bail out.
Fixes: #26697
d592558b8b cmLocalGenerator: Drop no-op link flag placeholder infrastructure
67639002ad Ninja,Makefile: Drop now-unused placeholders from link rule variables
951e4d3f62 Ninja,Makefile: Move builtin linker flags to <LINK_FLAGS> placeholder
6b618c6079 cmLocalGenerator: Clarify MODULE link flags placeholder population
c52a654aa1 cmLocalGenerator: Improve formatting of rule placeholder variable list
37cf9941ed UseEcos: Add missing placeholder in rules to link executables
fa61be5bc4 Embarcadero,OpenWatcom: Clear unused flags for creating shared libraries
124e40947c CMakeCommonLanguageInclude: Do not unset MODULE library flags when empty
...
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10869
0e53a67a7b cmFindPackage: fix over-reporting
8b3fc9578a cmFindPackageCommand: report found files to debugging infra
ee062ce4d0 cmFindCommon: test implicit configure log event reporting
a90598f17c cmFindCommon: support suppressing implicit event logging
5aefc8b7b8 cmFindBase: let the debug state know if it has already been found
928a74f684 cmFindCommon: always track configure log information
4fa647a544 Tests: Match RunCMake.try_{compile,run} configure log more precisely
Acked-by: Kitware Robot <kwrobot@kitware.com>
Tested-by: buildbot <buildbot@kitware.com>
Merge-request: !10783
Revert infrastructure from commit 8bcf9c7a3e (Add support of "LINKER:"
prefix for artifact creation flags, 2024-10-12, v4.0.0-rc1~522^2~1).
It is not needed to populate legacy placeholders with empty strings.
Previously we used separate placeholders for builtin linker flags:
* CMAKE_<LANG>_LINK_FLAGS for EXECUTABLEs
* CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS for SHARED libraries
* CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS for MODULE libraries
These correspond to variables set by our compiler information modules.
Teach the generators to look up these variables and add them to the
existing `<LINK_FLAGS>` placeholder instead. Substitute the empty
string for the old placeholders.
Issue: #21934
Modify the project command to always set COMPAT_VERSION variables, not
just if experimental CPS export support is enabled. This ensures that
these values are (at least as of the call to the project command) empty
and cannot be "preset" e.g. by command line arguments in the case that
experimental support is enabled after the project command is called.
External tools may create a `.xcworkspace` directory next to the
`.xcodeproj` directory that CMake generates. If a workspace exists,
drive the build through it instead.
Closes: #26958
Co-authored-by: Brad King <brad.king@kitware.com>
Clarify comments from commit 8bcf9c7a3e (Add support of "LINKER:" prefix
for artifact creation flags, 2024-10-12, v4.0.0-rc1~522^2~1) about
MODULE library creation flags. Also avoid falling back to EXECUTABLE
flag placeholders for SHARED or MODULE libraries. I don't think we
ever populate `CMAKE_<LANG>_CREATE_SHARED_{LIBRARY,MODULE}` from the
value of `CMAKE_<LANG>_LINK_EXECUTALBE`.
Commit aafd771529 (cmNinjaTargetGenerator: use `GetObjectFileDir` where
possible, 2025-05-21) from !10812 accidentally converted the
`GetTargetDependInfoPath` from an always-absolute path to a
relative-for-ninja path. This works fine as everything ended up doing
`ConvertToNinjaPath` as necessary *except* the code which actually wrote
the file. That needs an absolute path in order to generate it in the
correct location.
Fixes: #26983
`find_package` has different behavior where not all modes support
reliably knowing if a search has already happened in order to not always
report failing searches.
Brad King