Remove this special case handling for building a host library as a target
library. This is the last piece needed to support cross-compiling lldb. As a
bonus, it cleans up some of the logic in our special build system.
In https://github.com/apple/swift/pull/19973 the logic that adds "-target" when
building the C parts of the Standard Library and overlays was changed to use
CMAKE_C_COMPILER_ID to only do so when the compiler ID is "Clang". However,
on Apple toolchains the compiler ID is "AppleClang", so the target was no
longer being explicitly set.
Update the logic to relax the explicit check for "Clang" to also allow
"AppleClang".
rdar://problem/45579667
When building the target libraries, we need to install the import
library as well. Unfortunately, due to the way that the swift build
system works, we do not have the ability to rely on CMake doing the
right thing and taking care of this for us. We have to manually
construct and track the import library due to the fact that we fight the
cross-compilation support. Add some logic to extract the import
libraries and install them so that uses can actually build for Windows.
Debride the function now that it is handles only the host libraries for
the tools. These are closer in spirit to the LLVM libraries and this
function can really become a trivial wrapper around llvm_add_library.
The key thing here is that all of the underlying code is exactly the same. I
purposely did not debride anything. This is to ensure that I am not touching too
much and increasing the probability of weird errors from occurring. Thus the
exact same code should be executed... just the routing changed.
The Windows headers are the system (sysroot) headers. They are not
consumed by swift but the clang importer. Furthermore, they should be
treated as system headers. Correct the flags used for the invocation.
This fixes the build of the SDK overlay for Windows.
...i.e. an actual shell-like argument list, rather than a
semicolon-separated list (CMake's internal stringification mechanism
for lists). Apart from being a little easier to read, this also works
directly with the response file support in swiftc itself now (not
depending on utils/line-directive).
(It's still not /quite/ enough to expand on a command-line, though,
since that will escape the quotes. The 'sed' command can get around
that: $(sed "s/'//g" foo.txt).)
When building the swift tools with gcc, we would fail as we would try to
pass `-target` to gcc, which does not support this option. Invert the
condition and only pass the argument when building with clang.
Fix the parameter name in `_add_swift_library_single` which would
previously not pass any value for the `INSTALL_IN_COMPONENT` due to a
missed alteration when the function was refactored. Spotted by
inspection.
Use the simpler inline form of the check in most places. The two sites
that remain have multiple uses in a single function. It should be
possible to replace those as well, though it is unclear if the overhead
of inlining the check to all the places in the function will make a
measurable difference.
The Windows SDK proides kernel32.Lib which on case sensitive file systems will
fail (due to the capital L in the extension). Workaround that by creating
symbolic links to handle this. This mirrors the technique used in LLVM.
Extract the C++ header search path from the system header search path. This is
needed to ensure that we do not push the C++ headers into the swift compiler
search path. The reason here is that when building the module, we would attempt
to include the C++ headers, which we cannot do since the ClangImporter in swift
explicitly sets the langugage to C. This would break the stdlib build for
android.
Adjust the build to work with the VS2017 layout while maintaining the
compatibility with VS2015. The library location changed which results in the
link failing due to not finding system libraries.
Reduce some of the SDK configuration printing for non-Darwin
configurations. This simplifies the output and SDK configuration. The
parameter reduction simplifies the setup for cross-compilation.
The prefix and platform names are case adjusted values of the name of
the SDK. Compute the value rather than pass them down. The
simplifications will yield an easier cross-compilation implementation.
Rather than computing the triple first and passing it down to the SDK
configuration, hard code the triple into the SDK's configuration. This
is a value which is static and will allow us to configure
cross-compilation of the standard library for Linux. Although most
other targets do not support the same variety of architectures, this
enables those to be cross-compiled as well.
Remove the duplicated platform name parameter to the unix SDK
configuration.. This value is implicit currently and can be computed.
This needs to be computed to permit parallel co-installations of
architectures for targets which do not support fat binaries (i.e.
non-MachO targets).
The SDK is a sysroot. Permit the user to specify the location of the
SDK when building Linux. This is in preparation to cross-compile the
Linux standard library.
While we are exposing more control knobs to the user, we can start
simplifying `configure_sdk_unix`.
When cross-compiling the Windows standard library in release mode, we
would get undefined symbols due to LLVM invoking
`add_definitions(-D_DEBUG)`. This would change the behaviour of certain
functions from MSVCRT resulting in undefined symbols. Scrub out the
unwanted `-D_DEBUG`.
Commit to a command line option spelling so that build systems can
start testing it. I deliberately picked one of the longer names we
were considering because we can always decide to add a shorter alias,
but can't decide a shorter name was too generic.
Like the other supplementary output flags,
-emit-parseable-module-interface-path will emit a .swiftinterface file
to a particular path, while -emit-parseable-module-interface will put
it next to the main output (the one specified with -o).
rdar://problem/43776945
Merge two cases into a single case rather than keeping them separate.
Additionally check the condition early rather than perform the action
and then revert it. NFC.
Hoist out the some of the architecture independent variables outside of
the inner loop. This should simplify the logic for the function and
improve generation times. (NFC)
The SDK configuration can identify the triple for the android targets. This is
similar to the Windows behaviour. Doing so will now enable multi-architecture
builds!
The path to the SDK can be computed from the NDK. Do so to reduce the
parameters needed to pass to CMake. More importantly, this will allow building
with multiple architectures simultaneously.
The android specific configuration here is the same as the non-android in the
sense that it is setting up the triples for the target. Simply inline it as it
makes it more obvious what it is doing. This is preparatory work for adding
support for multiple architectures for Android.
This corrects the casing which would previously not match.
Unfortunately, the `MATCHES` operator also does not handle the case
insensitivity properly. This enables building just the standard library
on Linux for Windows.
This just cleans up the invocation generation for android to avoid passing in
`--sysroot=` twice to the driver with the same value. This has no impact, but
cleans up the command line so it is easier to see what is going on.
Clang's been able to read the textual format for a long time, and
indeed that's what's used in the SDK. This isn't even really a
performance win because the information is cached in PCMs.
rdar://problem/34293901
Visual Studio's compiler does not accept `-Werror=switch`. Use the equivalent
`-we4062` option instead. Avoid using the `--` separate that clang uses to
identify that the options that follow are files and not options on the Visual
Studio compiler to reduce the unnecessary spew when building on Windows.
