The initial configure & generate of a build on Windows should have
the necessary VCVARS set in the environment. After that, we should be
incrementally building with those same vars to avoid conflicts between
Windows SDKs.
Cache these vars so that the same Windows SDKs are consistently used
in future incremental builds.
When building on case insensitive filesystems, there is no need to
create the library symlink forest as the paths will be resolved properly
due to the insensitivity. This avoids a bit of work and spew on
Windows.
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.
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`.
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.
ndk14 introduced "unified headers" which merged the headers for all
different API versions into one directory which effectively split the
"SWIFT_SDK_ANDROID_ARCH_${ARCH}_PATH" into two different directories.
Add include and library specific paths to various compilation and link
invocations across the Swift project to account for this change. Remove
some broken sysroot/sdk specific settings.
Report the ICU I18N and UC include paths and the library path. This
makes it obvious when the variable is not defined and more importantly
makes it easier to see what the paths are being used particularly when
cross-compiling for multiple architectures.
General purpose cross compilation from host x to targets a,b,c will
require the ability to have multiple architectures passed to
`configure_sdk_unix`. Simply change the function to accept multiple
archs.
Cross-compilation for multiple architectures & sdks require various
variables to be split to specify the arch/adk variant being focused on.
This change modifies various uses of the `SWIFT_SDK_${SDK}_PATH` to
`SWIFT_SDK_${SDK}_ARCH_${ARCH}`
Set the deployment target to an empty string for non-Darwin platforms
so that it is safe to append to the target triple without guarding it
with a check for Darwin.
This change leaves in place the use of -m*-version-min options, but
fixes the -target options to match. We can eventually remove the use of
the -m*-version-min options after everyone has moved to build with
versions of Clang that correctly handle the deployment version in the
-target option.
Windows ARM NT (the modern, non-Windows CE environment) is a pure thumb2
environment. The frontend does not canonicalise the target like in
clang. Ensure that we map the triple by hand to the desired target
triple.
Rather than use the `INCLUDE` and `LIB` environment variables to build
the Windows code, use the `UniversalCRTSdkDir`, `UCRTVersion`, and
`VCToolsInstallDir` variables. Using these we can compute the right set
of include directories and library search paths for the various
architectures. This will enable us to build multiple variants of the
Windows stdlib at the same time.
Additionally, rather than relying on the magic environment variables to
be processed by the driver, pass them explicitly to the driver through
the build system. This also is needed to allow parallel builds of
various architecture variants of the stdlib on Windows.
When cross-compiling for android ARM, it is possible that the system
linker does not support the target. However, in order to cross-compile
the target runtime, we need to adjust the linker to the target linker.
If one is not specified, fall back to the current behaviour of using the
system linker.
Refactor configure_sdk_darwin(), remove the "internal" parameter since all calls are the same, make it respect SWIFT_USE_INTERNAL_SDK instead.
Make it use the internal SDK only if cross compiling tools, since it's required.
Swift SVN r31509
We will need this to switch the darwin targets over to use ICU instead of going
to NSString for string operations. The public SDK does not contain the headers
for ICU - only the dylib.
For builds using a public SDK users can specify the path to an ICU install where
the headers can be found. If this path is specified the logic will not use
internal SDK variants.
Swift SVN r31471
Un-revert the below commits with the following addition:
add declarations for posix_spawn related APIs to SwiftPrivateDarwinExtras.
posix_spawn-related APIs aren't available in the public SDKs, so force past
the availability by creating our own stubs in the internal DarwinExtras
library.
r31244, r31245
CMake: build all platforms except watchOS using the public SDK
Covers rdar://problem/21145996.
A step towards rdar://problem/21099318.
Switch SDK overlays to use the public SDK
I had to cut the dependency on CrashReporterClient.h and reimplement
some of that code inline in the Swift runtime. This shoud be OK (even
though not very clean), since the layout of CrashReporter sections is
ABI.
rdar://21099318
Swift SVN r31252
This reverts commit cd3f1ba7d1ee2397817e1a165209fdeab8a1c004.
Reverting this b/c it is breaking buildbots with the following:
CMake Error at CMakeLists.txt:522 (message):
CrashReporterClient library is required, but it was not found
Swift SVN r31047
- Add frontend and standard library build support for tvOS.
- Add frontend support for watchOS.
watchOS standard library builds are still disabled during SDK bring-up.
To build for TVOS, specify --tvos to build-script.
To build for watchOS, specify --watchos to build-script (not yet supported).
This patch does not include turning on full tests for TVOS or watchOS, and
will be included in a follow-up patch.
Swift SVN r26278
