Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
Account for import libraries and the associated layout difference on
platforms (e.g. DLLs are placed in `bin`). This is required to enable
building the macro path on Windows.
As of CMake 3.25, there are now global variables `LINUX=1`, `ANDROID=1`,
etc. These conflict with expressions that used these names as unquoted
strings in positions where CMake accepts 'variable|string', for example:
- `if(sdk STREQUAL LINUX)` would fail, because `LINUX` is now defined and
expands to 1, where it would previously coerce to a string.
- `if(${sdk} STREQUAL "LINUX")` would fail if `sdk=LINUX`, because the
left-hand side expands twice.
In this patch, I looked for a number of patterns to fix up, sometimes a
little defensively:
- Quoted right-hand side of `STREQUAL` where I was confident it was
intended to be a string literal.
- Removed manual variable expansion on left-hand side of `STREQUAL`,
`MATCHES` and `IN_LIST` where I was confident it was unintended.
Fixes#65028.
The dependency of the Observation library on the observation macro
plugin introduces a direct dependency of a target library on a host
library, (lib -> stdlib) that we'd like to avoid. Instead, make the
Swift frontend binary depend on the macro plugin libraries that we
build, so that it's the complete host-side stack.
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.
Internal configurations targeting Darwin employ ThinLTO to
improve compiler performance, however using it on all executable
causes build time to increase with no matching benefit.
To reduce build times in such configurations, we allow some
ancillary targets to opt out of LLVM IR optimizations when linking
ThinLTO with ld64 (e.g. tools used for bootstrapping or debugging the
Swift compiler) -- this behaviour is opt in through a new flag
`--swift-tools-ld64-lto-codegen-only-for-supporting-targets`.
Addresses rdar://76702687
A `/${CMAKE_CFG_INTDIR}` was missing in a path. With Ninja, this does not matter because then it is always "". But with Xcode, it is "Debug", "Release", etc..
Unfortunately using the convenient "bootstrapping0-all", etc. custom targets does not work.
For some reason it does not cause a dependent file (like libswift's SIL.o) being rebuilt when a depenency (like swift-frontend from the previous bootstrapping stage) changes.
Instead we have to list al library- and executable-targets explicitly.
Don't build the swiftCore module files in the bootstrapping phases. Instead use the module files in the SDK.
This reduces the build time overhead from 3min -> 30seconds.
The SwiftDriver searches `swift-frontend` based on `Bundle.main.executablePath` (which internally uses `CFGetProcessPath`). This search dir is resolved differently on macOS and Linux so swift-frontend can't be found on Linux, forcing the driver to fallback to using the host system toolchain instead of the just-built one.
Adding build modes for libswift: off, hosttools, bootstrapping, bootstrapping-with-hostlibs
The two bootstrapping modes are new. For details see libswift/README.md
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
