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!
I put in a small little kludge to add support for this. The better solution is
to refactor the supports_benchmark property from Platform to Target. We
already have a similar abstraction problem with armv7 target on Darwin, where we
explicitly turn off benchmarking.
*NOTE* Building the benchmarks for linux still requires more cmake work. I am
making some changes in a subsequent commit series to do this. If you try to
compile the benchmarks, you will hit an error where ninja says that it doesn't
know about the swift-benchmark-linux-x86_64 target.
build-script-impl assumes ICU is located at
```
LIBICU_SOURCE_DIR="${WORKSPACE}/icu"
```
However, build-script would try to set it to
```
<path-to-workspace>/libicu"
```
This is wrong, so fix it
Some cmark CMake stuff changed recently and the default rules
we have in the Python build script code doesn't behave correctly
anymore, likely because it was relying on incorrect settings.
Now, by default, if the cmark build type isn't specified, it will
follow Swift's. If we don't do this, Xcode builds are broken, and
building with Xcode is important.
This should help speed up people trying to compile the standard library and do
SILGen work. *NOTE* This will not necessarily result in a type checker that is
as fast as a release build since most likely the type checker will use some
link_once odr functions that are debug. But it should still be significantly
faster otherwise.
This makes getting to SILGen take 16 seconds on my machine instead of forever
when compiling with everything else in the compiler in debug mode.
lock is not initialized. Thus, we initialize the lock to None and just
don't use it because no console output can happen in parallel because
we're not running in parallel.
