Xcode automatically adds a flag matching the generated `LIBRARY_STYLE`:
* For SHARED libraries we've been duplicating `-dynamiclib` with a copy
in `CMAKE_SHARED_LIBRARY_CREATE_<LANG>_FLAGS`. Remove it for Xcode.
* For MODULE libraries we've been not duplicating `-bundle` only by accident.
Since commit 586a9427d3 (ENH: Created target property INSTALL_NAME_DIR...,
2006-02-24, v2.4.0~418) we've looked up `CMAKE_<LANG>_LINK_FLAGS`, meant
for EXECUTABLEs, instead of `CMAKE_SHARED_MODULE_CREATE_<LANG>_FLAGS`.
Switch to the latter, but remove `-bundle` for Xcode.
92d6126450 MSVC: Move link -machine flag out of CMAKE_*_LINKER_FLAGS
bb8baacbcc MSVC: Factor out link -machine flag name
4c6c7f4d45 MSVC: Move link -subsystem flag handling near and -machine flag handling
f1a80a5581 CUDA: Drop unused link rule variable setting on Windows
a0732ce47f CMAKE_STATIC_LINKER_FLAGS: Fix terminology in cache entry help string
53aab8acd6 Tests: Generalize test name RunCMake.MSVC{Warning => Default}Flags
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10849
The `CMAKE_{EXE,SHARED,MODULE,STATIC}_LINKER_FLAGS` variables are
not language-specific, so multiple languages' toolchains may disagree
about if/how to pass the flag through a compiler driver to the linker.
Furthermore, carrying the flag in public-facing variables allows projects
or users to change it even though it is required. Add policy CMP0197
to remove the flag from the public-facing variables and generate it
automatically instead:
* For command-line generators, add the `-machine:` flag to the
linker and archiver rule variables.
* For Visual Studio generators, we do not need to explicitly add the
link `-machine:` flag. MSBuild automatically adds it, and the new
behavior actually removes a duplicate we generated previously.
Issue: #21934
It effectively created a control file with two stanzas when package file
data is appended, one of which lacks required parameters, making this
package impossible to use in a package repository.
Fixes: #26975
Add support for specifying CPS's supplemental `description` and
`website` attributes. Add ability to inherit these from the `project()`,
similar to how version information can be inherited.
Add some helper functions to simplify some repetitive code dealing with
CPS metadata. The duplication isn't bad now, but in the future we will
be handling additional properties that will benefit from these helpers.
`Microsoft.Cl.Common.props` adds some `cl` flags by default, but for
CMake they may not match what's produced by command-line generators.
If the `-Zc:wchar_t`, `-Zc:forScope`, and/or `-Zc:inline` flags are
not specified by the project or user, suppress them.
Fixes: #26964
Modify {export,install}(PACKAGE_INFO) commands to inherit version
information from the current project in situations where it seems
reasonable to do so. Add an option to explicitly request inheritance
from a specific project.
This leverages the recently added project(COMPAT_VERSION).
Add a member to directory state that records the set of known projects.
Add a method to query whether a project exists.
Internally, while this doesn't allow us to confirm that a variable like
`foo_VERSION` is actually associated with a project `foo`, it provides a
much stronger indicator than the mere existence of said variable.
CPS package metadata involves a fair amount of passing around a
particular set of values, as well as shared argument handling, which is
only going to increase as additional features are added. In order to
reduce code duplication (now and going forward), create a helper class
to handle the shared argument parsing and to serve as a container to
pass metadata values.
cdf2a36f48 HIP: Add support for [CMAKE_]HIP_LINKER_LAUNCHER
77312cc636 CUDA: Add support for [CMAKE_]CUDA_LINKER_LAUNCHER
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !10847
Explicitly allow argument markers to be assigned. Make use of this in
parsing. This simplifies working with these types, by allowing them to
be assigned from the underlying types using simple `a = b` syntax,
rather than requiring gymnastics to access the underlying assignment
operations. It also makes assignment more consistent with
initialization.
In cmProjectCommand, after validating the VERSION, we move it into a
local variable. Later, however, we were comparing COMPAT_VERSION against
the VERSION stored in the arguments. Compare to the local variable
instead.
With IntelLLVM on Windows, we link using the compiler driver.
With MSVC on Windows, we invoke the linker directly. If we
use both in a single build tree, for separate languages,
the value of `CMAKE_LINK_DEF_FILE_FLAG` conflicts. Add a
per-language `CMAKE_<LANG>_LINK_DEF_FILE_FLAG` variable to
avoid the conflict. Preserve the language-agnostic variable
for compatibility with projects that reference it.
Fixes: #26005