If one is building Swift against an instrumented LLVM build, when the
functions in AddPureSwift.cmake tries to link Swift code that also links
LLVM instrumented code, the linking will fail because the linker will
not use the profiling runtimes.
The modifications replicate the existing code in LLVM
HandleLLVMOptions.cmake, but adapted to Swift variables where possible.
The necessary arguments are forwarded through `-Xclang-linker` because
the spelling of the Swift driver does not give access to all the options
that Clang provides.
This has been tested with an unified build, but a standalone build could
still pass the `LLVM_*` variables to the Swift build system to make use
of this code.
Changes to the headers imported by Swift files aren't not correctly
propagated in CMake/Ninja. So changes to C/C++ headers didn't rebuild
ASTGen modules. Move the similar hack from SwiftCompilerSources and use
it in ASTGen as well.
rdar://120863405
Swift-driver PR [1043](https://github.com/apple/swift-driver/pull/1043)
updated the new driver to always emit private swiftinterface files.
This was not carried back to the old driver, so attempting to bootstrap
the toolchain on a system that does not have the new driver fails to
install because we try to install the private swiftinterface on all
Swift targets.
Add the swiftmodule paths for ASTGen via
`-add_ast_path` to the public linker flags such
that downstream linking picks them up, allowing
LLDB to load them when debugging. Also switch
SwiftCompilerModules to using public linker
flags instead of adding the linker flags in
`_add_swift_runtime_link_flags`.
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.
This wires up the new macro properly into the build machinery to ensure
that the `distribution` target properly builds and installs the
dependencies. This fixes the missing `swift-plugin-server` on Windows.
`:` is not a valid file system character but is used to namespace the
imported targets. This is then used to create the stamp file. Sanitize
the name prior to use as a stamp file name.
"Support Macros in Linux" patches was inconsistent with checking
platforms. Some only checked 'LINUX' but some matches
'LINUX|ANDROID|OPENBSD|FREEBSD'. Although I don't have tested other
platoforms than Linux at all, there's no reason to limit it to Linux.
So use the consistent check to match 'LINUX|ANDROID|OPENBSD|FREEBSD'
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
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.
`.swiftmodule` is listed as an output of pure swift libraries, but it
isn't updated if there's been no changes (just like the library and
its object files). Add it to the touch hack as well.
Swift *executables* also list `.swiftmodule` as an output, even though
one isn't generated at all. Add a new POST_BUILD command to touch it
regardless.
* Move `add_pure_swift_host_library()` from lib/CMakeLists.txt to
AddPureSwift.cmake so that code outside `lib` can use it
* Add `add_pure_swift_host_tool()` function to make a pure Swift
host executable target (for future usages)
* Specify depending `SwiftSyntax` modules explicitly because not all
Swift libraries uses all SwiftSyntax libraries
