Certain versions of CMake behave differently with variable expansion. This may
be evaluated incorrectly in some versions. Dereference the value explicitly.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This is a resubmission (with modifications) of an earlier change. I originally
committed this but there were problems with some installation rules.
This commit introduces a CMake target for each component, adds install targets
for them, and switches build-script-impl to use the target `install-components`
for installation. Each of the targets for each component depends on each
of the individual targets and outputs that are associated with the
corresponding swift-component.
This is equivalent to what already exists, because right now install rules are
only generated for components that we want to install. Therefore, this commit
should be an NFC.
This makes it more explicit what the install component of a target
library is if you don't see one (and its marked as IS_SDK_OVERLAY).
Explicit in this case makes more sense, as you don't have to rely on
knowledge of how `add_swift_target_library` is implemented to understand
what component is used to install the target.
This option should be `SWIFTLIB_SINGLE_TARGET_LIBRARY`. If you rely on
`SWIFTLIB_TARGET_LIBRARY`, you get whatever was set in add_swift_target_library.
While these should be the same, I'm trying to remove `SWIFTLIB_TARGET_LIBRARY`
entirely.
Check if building on Android through the ANDROID_DATA environment variable, then set
SWIFT_ANDROID_NATIVE_SYSROOT to the default layout for the Termux app, and key all the
include, lib, and other SDK paths off of that. The system libc and a few other libraries
are linked against from /system/lib[64]. Finally, check if lit is running natively on
Android and don't use adb if so.
add_swift_target_library should always have `TARGET_LIBRARY` set. A few
lines down, there is a precondition that makes sure that it is set. This
check and subsequent assignment of `SWIFTLIB_INSTALL_IN_TARGET` should
never get triggered.
When installing a target, you could have multiple target files with
different rules for installation. For example, you can specify rules for
`RUNTIME` files, `LIBRARY` files, `ARCHIVE` files, etc. Each of these
can take several options, e.g. `DESTINATION`. When you want to specify
the install component for a target, each of the different target file
rules need to have their own `COMPONENT` field. If not, they end up as
"Unspecified" which means they will not get installed with the
associated swift component.
The system headers should be given lower priority than the user
specified headers. This requires that we include the system C++ headers
as `-isystem`. Without this, it is not possible to use a custom
toolchain to replace the clang compiler for building the android
runtime.
On Android, we explicitly setup the include paths for the C++ headers.
As a result, we do not want to pick up any system headers that the
toolchain may have visible to it. If this flag is not added then clang
will look in the wrong places to get the headers for things like stddef
etc.
Use the `FindLibEdit.cmake` module from LLDB to properly control where
the libedit libraries are searched for and linked from as well as where
the headers come from. This uses the standard mechanisms which allows
users to control where libedit is pulled from (which is important for
cross-compilation).
Some versions of CMake dereference the variable here and others do not.
Explicitly dereference to ensure that the library name is properly set.
Failure to do so will fail to load the library as the output path
becomes the name.
This converts the local variable to a cached variable which the user can
specify. By making this a cached variable, it is easier to control and
ensure that a default value is provided.
Rather than hardcoding the paths to /usr/include, allow the user to set
the path to their libc headers. This is particularly important for
environments which may not use the traditional layout (e.g. exherbo) or
for builds which wish to build against an out-of-tree, non-system
installed libc for a Unix target which does not match the host system
(i.e. foreign cross-compilation).
This just reorders the printed order of the messages to be grouped
better. This will be further augmented in the next set of changes which
improve the cross-compilation setup that we have currently to allow for
foreign environments better.
The clang in the android NDK (as well as the current stable Clang in
Swift) have a bug with Android x86_64 targets where the CPU's 16-byte
(double-word) CAS instruction feature is disabled resulting in the
double word CAS being lowered to a libcall
(`__sync_val_compare_and_swap_16`) rather than the CPU instruction
(`cmpxchg16b`). This results in the inability to link the content.
Work around this by enabling the feature manually in the build for now.
This is needed for cross-compiling the toolchain to Windows ARM64 on
Windows x64 using Visual Studio which does not permit the NATIVE
sub-build to work properly.
We use one bit of the third reserved swift private tls key.
Also move the functionality into a separate static archive that is
always linked dependent on deployment target.
