Only introduce it and its dependency when the new Swift parser is being
built, and rely more on existing logic to make sure we get the right
build/link flags.
Refactor the logic so to have a single target to reference the
compatibility libraries for the host, and use that when needed.
The main driver for this change is supporting the cross-compilation of
x86-64 on Apple Silicon.
Supports rdar://90307965
The switch between compilers causes problems due to new flags being used
for building. This adds a workaround to avoid the search path
re-ordering which breaks the build with a newer CMake.
When installing both InProc and XPC versions of sourcekitd, dynamically
link the XPC service to the InProc version. This lets us install both
frameworks without wasting the disk space from having another copy of
the swift frontend statically linked.
Reduces duplication with llvm and, more importantly, gives us Linux
support via a linker script. This will let us link libsourcekitdInProc
in binaries that have their own copy of llvm symbols on Linux, and let
sourcekit-lsp stop using dlopen with `RTLD_DEEPBIND`, which fixes
running with asan among other things.
Convert the out parameters for `_add_host_variant_c_compile_flags` to
use the target as an in-parameter. Doing so allows us to set the
properties on the target directly rather than providing them as out
parameters which then get set subsequently.
Convert the out parameters for `_add_host_variant_link_flags` to use the
target as an in-parameter. Doing so allows us to set the properties on
the target directly rather than providing them as out parameters which
then get set subsequently.
Apply constant value propagation to the host flag variant operations.
This reduces the parameters needed for the invocations and enables
further cleaning in the hopes that we can apply these per-target using
CMake instead.
This should repair the Windows build after #29451. The quoting
behaviour was incorrect and was constructing an invalid compiler
invocation. Solve the issue by using `target_include_directories`
instead. However, since this needs the target, hoist the flag
computation to the local sites. This replicates more logic because of
the custom build trying to replicate the CMake build logic in CMake.
Use specific operations for setting the compile flags, link flags,
linked libraries, and library search paths. This allows us to use CMake
more effectively, simplifies the logic, and will ensure that flags are
not duplicated.
This moves the handling of the RPATH and the exported symbol to the
binary themselves. The exported symbol is needed due to the use of the
exported symbol list. This makes the small difference that `_main` is
always exported on Darwin which is not strictly needed in ASAN as ASAN
provides the entry point.
The RPATH is only setup on installation which is sufficient for testing
purposes as CMake ensures that the libraries are fully linked and will
be loaded properly when run from the build tree.
I think this was just an oversight. The new cmake 3.16 seems to choke if we do
not add SourceKit to the exports file since there are dependencies upon it in
other swift libraries.
Now that CMAKE_HOST_SYSTEM_NAME and CMAKE_SYSTEM_NAME are set by default to
Android in the Termux app, make the needed tweaks. Some tests were adapted
to work natively on Android too, adds sys/cdefs.h to the Bionic modulemap,
and includes the start of native Android platform support in the build-script.
This removes the custom `LINK_LIBS` in favour of
`target_link_libraries`. This simplifies the custom functions that we
have for adding libraries, makes it easier to query the information from
ninja and will allow us to slowly remove more of the custom logic for
building the products.
When building in a unified build and building the host tools with a
non-clang compiler, we switch compilers. In such a case, we need to
actually add an explicit dependency on the new compiler.
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.
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.
CMake supports the notion of installation components. Right now we have some
custom code for supporting swift components. I think that for installation
purposes, it would be nice to use the CMake component system.
This should be a non-functional change. We should still only be generating
install rules for targets and files in components we want to install, and we
still use the install ninja target to install everything.
add_sourcekit_default_compiler_flags was invoking
_add_variant_link_flags and getting link flags but not actually using
the link_libraries or library_search_directories. In android builds,
this means that the correct libc++ is not being linked against.
`-fblocks` is a core driver option now, so it can be used with both the GCC
style driver as well as the cl style driver. Simplify the logic for the
handling of this option.
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.
Ensure that we install the client header for the InProc sourcekitd. This is
needed to actually make it usable. With this, it is now possible to develop
against SourceKit on Linux and Windows.
Set all the target properties in a single shot. This avoids the multiple string
parsing within CMake. Although this makes no noticable differnce, it is
slightly more efficient and also colocates all the target properties.
SourceKit's build is now ammenable to building for Windows. Generalize the path
to enable building it for Windows as well as Linux. The libdispatch build for
the compiler is needed for all non-Darwin targets currently.
Not all targets (CMAKE_SYSTEM_NAME) use `lib` and `.a` for the static library
name. Adjust the name properly for the host that we are building for. This
repairs the build when performing a cross-compile from Linux to Windows.
This is useful because the embedded platforms may have the same toolchain version but they contain
different stdlibs. We need to make sure the XPC service name is unique between them, otherwise we may load
and use the incorrect toolchain service.
rdar://39077520
