This is a cleaner, more principled way of adding "compiler launcher" support and
ensures that cmake understands that distcc is not the "actual" compiler.
This ensures that when we compile SwiftRemoteMirrors for the host, we do not try
to compile using distcc without needing to reset CMAKE_{C,CXX}_COMPILER_ARG1
(which is unset when compiling things in the stdlib).
Add support to build-script to build and test the indexstore-db and
sourcekit-lsp projects. A future change will add support for installing
these products and putting them in the toolchain. To build the new
products, add the `--sourcekit-lsp` or `--indexstore-db` options to a
`build-script` invocation.
We add the notion of a Product that is not part of build-script-impl and
build these products after the install phase of build-script-impl. These
products are built using the installed toolchain - either using the
default location within the build subdirectory, or the user-specified
`--install-dest`. This is somewhat rigid setup, since it requires the
toolchain used to build to be the same as the final installed toolchain
(if any), but it makes for a simpler change to the existing builds while
still making progress towards a toolchain-based build model.
*Note*: currently, if you are not using a preset you will need to
manually specify all of the dependencies (on macOS this is
swiftpm and llbuild, on other platforms you additionally need
libdispatch, icu, foundation, and xctest), and the install flags for the
same projects (`--install-llbuild --install-swiftpm ...`). This is not
particularly user-friendly, but it matches the current behaviour of the
other targets, and there is not yet any infrastructure in build-script
to describe these dependencies.
Turns on the `--no-legacy-impl` option to build-script by default; the
old behaviour is temporarily still available as `--legacy-impl`.
This causes build-script to invoke build-script-impl for every
individual build/test/install/etc. action rather than a single global
invocation. For example, a single invocation might be for
`macosx-swift-install`. This will enable the python code in build-script
to drive the overall process and add additional steps in between actions
without the involvement of build-script-impl. It also provides a path to
refactoring the existing actions out of build-script-impl individually.
Discussed as part of https://forums.swift.org/t/rfc-building-swift-packages-in-build-script/18920
The --no-legacy-impl flag was originally disabled by default because of
concerns about the performance of null builds due to the increased
number of script invocations. There is a small optimization in this
commit to use `tr` when processing command-line options instead of
bash's builtin substitution, which eliminates most of the overhead.
After this change, a null build of llvm+swift changes from 1.6 s to
2.1 s on Linux, and from 5 s to 6 s on macOS. Non-null builds and
builds that involve more build products than just llvm+swift (e.g.
corelibs) are basically unaffected since they are not correctly
incremental to begin with.
The changes to build-script-impl in this commit are to fix the behaviour
of --no-legacy-impl, which had bitrotted since it was introduced. These
changes are to make various parts of the script not rely on variables
defined in "earlier" parts of the script, which is good hygiene in
general.
Support for Android aarch64 in many parts of the build-script. Most of
the changes are reuse variables/parameters that already existed for
Android ARMv7. There is also a new parameter to specify the ICU
data library, which is used by #19503.
With this one can build either armv7 or aarch64, since building both
at the same time requires more changes like #19432 (and probably
more work to support two set of paths).
Prior to this, the swift build didn’t understand what i686 is, or what to do about building it. This unblocks building, but will still run into build breaks.
* Updated the PathType and StorePathAction classes to allow for asserting if a path contains an executable.
* Converted the top-level argument group to use the new builder DSL.
* Updated tests for StorePathType to not actually test the functionality of the PathType class.
* Implemented a CompilerVersion type to mimic the existing wrapper in swift_build_support and return a more detailed object from ClangVersionType and SwiftVersionType.
* Updated action tests.
* Fixed a filter() mistake.
* Code review.
* Added new OptionalTrueAction and OptionalFalseAction classes to the arguments module.
* Fixed missing return statement in help-test generator.
* Renamed all the `skip_build_*` names to the more simple and affirmative `build_*`.
* Renamed all the `skip_test_*` names to the more simple and affirmative `test_*`.
* Added documentation to the OptionalTrueAction and OptionalFalseAction classes.
This only enables the swift compiler (not its output) to be used with leaks
sanitizer on linux.
Some important notes: On Linux, right now we are not completely leak clean. I
was only able to get a -Onone build of the stdlib without triggering lsan (I was
unable to run the optimizer and the tests successfully). Additionally even at
-Onone, I had to suppress some leaks in the driver. The point of this though is
to prevent any further -Onone leaks from being committed to the tree since
-Onone leaks that are not bounded (unlike the driver bugs) could cause SourceKit
to leak memory. Since SourceKit is a long running process... such a type of leak
would be bad.
rdar://32876901
Why are the python reasons for having our code nested in a directory
called ``swift_build_support.swift_build_support/`` instead of simply
``swift_build_support/``? Is that what we really want here?
In a normal swiftless clang build, if it doesnt know CLANG_VERSION_*,
clang's cmake falls back on LLVM_VERSION_*. We pass a CLANG_COMPILER_VERSION
to swift, but it is not necessarily what clang wants to know.
The intention of this CLANG_VERSION_* flag in Clang is to know
what Swift calls clang_user_visible_version. This is the non-specific
version of Clang. For example, clang-900 - this is 9.0.0, while Swift
would like clang_compiler_version to be the specific version that the
driver will print out.
Flag naming!
Fix tests
Fix the mocked output files of swiftc. Change the lookup of
clang from build-script to build-script-impl like all the other
commands. Pass more args to LLVM. Fix swiftenv creation. Fix unit tests.
The reason this patch works is that build-script-impl gets
all the arguments that are not handled by build-script.
Today, when you enable ASAN, build-script just reconfigures your normal build
directory to use ASAN. This forces you to recompile LLVM and Swift with ASAN
enabled and then (once you have finished using ASAN) to recompile LLVm/Swift
without ASAN.
By using a different build-directory, one still has to (potentially) recompile
LLVM/Swift, but one's original directory has not become invalidated. Thus when
you switch back to a normal build, one does not have to recompile LLVM and
(potentially) Swift!
