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`.
