Adding `SWIFT_ENABLE_SWIFT_IN_SWIFT` option to enable or disable the
parts of Swift that require a Swift compiler to build. This is meant for
bootstrapping compilers on new platforms and is not guaranteed to result
in a compiler that will pass the test suite.
This option is on by default so that folks won't forget.
If the option is off, the resulting compiler does not include the Swift
optimizer sources in SwiftCompilerSources nor does the resulting
compiler have swift macro support.
swift-compatibility-symbols, swift-def-to-strings-converter,
and swift-serialize-diagnostics don't use any Swift modules. But when
SWIFT_SWIFT_PARSER was enabled, they are linked with swiftCore. But
these binaries can be executed before the runtime is being built.
We need to stop them linking with swiftCore.
In Linux. Instead of setting temporary "fallback" RUNPATH, Set
LD_LIBRARY_PATH to builder's runtime when building standard library.
So we don't need to strip the temporary RUNPATH when installing.
`add_custom_target_command` has a note in its documentation that ask for
all the `COMMAND` arguments to immediately follow the first argument, or
the function will misbehave.
In the two cases below, the `COMMAND` arguments were after the `OUTPUT`
multivalue, and ended by mistake inside the `OUTPUT` parameter. This
kinda works because CMake will interpolate those back, but causes
problems for dependency resolution, marking many targets as dirty. When
one of those targets is dependent by the compiler, this can create
a huge cascade rebuild.
Fix the two cases I found where `add_custom_target_command` was used
incorrectly. This removes cascade rebuilds in my working directory, and
hope it applies to everybody.
