The configuration previously handled Linux properly but did not function
on macOS as `ld64` does not support `:` delimited paths. Account for
that by setting it to the empty string which will use multiple
invocations of the `-Xlinker -rpath -Xlinker ...` pattern to compute the
correct RPATH.
This adds logic to properly handle Swift executables. Only executables
marked as exporting symbols will now generate module interfaces for the
executable.
This moves the definition of the import library flags for Windows into a
platform specific file (much like the Darwin `-sdk` flag). This is in
preparation for re-use of the flag to make the flags handling for
executables more precise.
Darwin also has the concept of RPATH. Additionally, the flag is
identical to that on other Unixish platforms. Simply avoid the `-rpath`
handling on Windows.
This enables the use of `BUILD_WITH_INSTALL_RPATH` and `INSTALL_RPATH`
with Swift targets on Darwin.
Adjust the shared object rule to ensure that we honour the
`INSTALL_NAME_DIR` property on Swift targets. This enables the use of
`INSTALL_NAME_DIR` and `BUILD_WITH_INSTALL_NAME_DIR` on Darwin with
Ninja.
Define the RPATH separator to `:` so that CMake can reserve room to edit
the ELF RPATH at install time. This enables the use of `BUILD_RPATH` and
`INSTALL_RPATH` with differing values.
`-num-threads` is for the threading, not the job control. Use `-j` to
launch the parallel jobs. This enables parallel builds for Swift again
after driver updates preventing the parallelization through
`-num-threads`.
The rules did not account for the import library location (through
`<TARGET_IMPLB>`) and instead would always write the import library to
the default location (next to the shared library/executable). This
prevented the use of `CMAKE_RUNTIME_OUTPUT_LOCATION` and
`CMAKE_ARCHIVE_OUTPUT_LOCATION`.
This enables the use of MSVC and Swift on Windows in a single project.
MSVC uses no flag to indicate linked libraries while Swift uses `-l`.
Add support for a language specific link library flag which takes
precedence over the global `CMAKE_LINK_LIBRARY_FLAG` which preserves
compatibility with earlier releases.
The Swift driver recently learnt how to generate static libraries using
the `-static` flag. This enables us to generate proper static libraries
with dependency tracking with Swift as well.
This changes the behaviour of the generators to use a per-language
library search path flag. This is needed for multi-language projects
with different compilers (e.g. cl + gfortran). Since the adjusted
variable has been part of the user settings, we control this based on a
policy.
Fixes: #19307
Swift's driver will invoke the C++ driver (`clang++`) to invoke the
linker. Additionally, it will configure the command line to deal with
the linkage runtime support object (`swiftrt.o` or `swiftrt.obj`) to be
added at the right time (similar to C/C++). Since it indirects through
`clang++` it will properly setup the linker invocation for C++ and C as
well. This should permit the correct linker driver to be invoked in
multi-language projects.
Closes#19299
The response file was being written but not used due to the wrong
variable being configured for Swift. Swift does compile+link in a
single phase and does not use the `<OBJECTS>` placeholder. Use the
`<SWIFT_SOURCES>` placeholder instead for the response file substitution
which serves the same purpose.
Since the Swift model does a single compile/link phase, we would not
get the compile definitions, includes, and options past along to the
build of the module. Compute these for the target when constructing
the main command.
This adds support for the newly minted `-libc` flag to the Swift driver
invocation. These allow users to control the MSVC linkage properly on
Windows targets.
Swift supports frameworks and uses them across all OSes. They are added
using the `-F` flag. There must be a space following the flag and
before the parameter.
The include flag specifier should be specified multiply. The separator
was being misused for adding a space after the `-I` flag. Correct this
to get multiple include paths correct.
Create a `CMAKE_EFFECTIVE_SYSTEM_NAME` variable to use for looking
up compiler information modules instead of using `CMAKE_SYSTEM_NAME`
directly. This will allow multiple platforms to share the same set
of compiler information modules without spelling out all of them.
Issue: #17870
Per-source copyright/license notice headers that spell out copyright holder
names and years are hard to maintain and often out-of-date or plain wrong.
Precise contributor information is already maintained automatically by the
version control tool. Ultimately it is the receiver of a file who is
responsible for determining its licensing status, and per-source notices are
merely a convenience. Therefore it is simpler and more accurate for
each source to have a generic notice of the license name and references to
more detailed information on copyright holders and full license terms.
Our `Copyright.txt` file now contains a list of Contributors whose names
appeared source-level copyright notices. It also references version control
history for more precise information. Therefore we no longer need to spell
out the list of Contributors in each source file notice.
Replace CMake per-source copyright/license notice headers with a short
description of the license and links to `Copyright.txt` and online information
available from "https://cmake.org/licensing". The online URL also handles
cases of modules being copied out of our source into other projects, so we
can drop our notices about replacing links with full license text.
Run the `Utilities/Scripts/filter-notices.bash` script to perform the majority
of the replacements mechanically. Manually fix up shebang lines and trailing
newlines in a few files. Manually update the notices in a few files that the
script does not handle.
CMake used to put all header search paths into HEADER_SEARCH_PATHS
attribute. Unfortunately this attribute does not support to declare
a search path as a system include.
As a hack one could add a -isystem /path to the cflags but then include
ordering is not deterministic. A better approach was chosen with this
patch by not filling HEADER_SEARCH_PATHS at all and to populate
the C, C++, and Fortran flags directly. The include paths used by
Xcode should be now identical to the ones used by Unix Makefiles and
Ninja generator.
Allow the `Swift` language to be enabled with the Xcode generator for
Xcode >= 6.1. Reject it on other generators and with older Xcode
versions. Since Apple is the only vendor implementing the language
right now, the compiler id can be just `Apple`.
