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).
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.
SR-237 calls for `build-script` and `build-script-impl` to be merged. This
commit takes another step towards that goal by moving the logic that finds
the path to the CMake executable up into `build-script`.
Users of `build-script` were previously able to specify which CMake
they wished to use via `build-script-impl` args, like so:
```
$ utils/build-script -- --cmake=/foo/bar/cmake
```
This commit preserves that behavior, while also allowing users to
specify that path via `build-script` args:
```
$ utils/build-script --cmake=/baz/cmake -- --other --flags
```
