These are computed by build-script and passed directly by build-script-impl into
cmake for the relevant target. We can now start to migrate per product cmake
options from build-script-impl into build-script.
There may be some issues building compiler-rt with modules. Temporarily
disable the module build by default until we know more.
rdar://problem/27019000
Before this patch, it would not actually do anything unless
compute_cmake_llvm_tool_disable_flags()
was called, which is currently dead code, in the state of
build-script-impl currently.
I am preparing a different PR that reverts this change and will be merged for
swift-4.
This is disabled by default so on the builders it should be NFC.
This actually became a no-op since the build-script-impl triggered instance of
LLVM_INCLUDE_TESTS is always put strictly after this instance of setting the
cmake variable on the cmake line.
These are parts of LLVM that Swift strictly /never/ uses, but are used by LLVM
for testing. In a future commit, functionality will be added to build-script to
test LLVM.
Other parts of LLVM that can be used by Swift depending on ones configuration
will be disabled in a future patch via the introduction of a new components
system.
Communicate build variant selection to libdispatch build process
using the --with-build-variant argument to libdispatch's configure
script added in libdispatch pull request #110.
While it would be great to leave this as an option only configurable by a change
to the script, it is important that we make this configurable from the command
line so that we can reduce the work needed to be done when compiling with full
LTO.
This is trivially correct due to the way we convert build-script-impl args to
variables (i.e. llvm-targets-to-build => LLVM_TARGETS_TO_BUILD).
rdar://24717107
since the interprocess version likely won't be available for quite some time
given that libXPC hasn't yet been ported, and the in process version nearly
works.
This is NFC since SourceKit still isn't built by default on Linux.
This is important for a few reasons:
1. It ensures that on all platforms we use the just built clang to compile
compiler-rt. This ensures that the clang used to compiler-rt has all of the
features necessary to compile compiler-rt in the face of changes in the
underlying implementation.
2. It ensures that all platforms build compiler-rt in the same manner.
In LLVM, the convention is that *_INCLUDE_* means that cmake will generate
targets but says nothing about whether or not something will be built by default
or not. This means that as far as cmake is concerned, those targets do not
exist.
On the other hand, *_BUILD_* determines whether or not a class of things is a
dependency of the "all" target. Of course this implies that *_BUILD_* implies
that *_INCLUDE_* must be set to TRUE.
Currently SWIFT_BUILD_TOOLS is implemented like a *_INCLUDE_* option, so change
its name to SWIFT_INCLUDE_TOOLS.
This was already in build-script-impl in the guise of SKIP_COMPILER_RT. This
just makes the name canonical (i.e. SKIP_BUILD_COMPILER_RT) and also exposes it
via build-script-impl's interface.
This enables you to know what tests actually ran instead of just the number of
tests that ran. This helps identify:
1. Tests that are not running, but /should/ be running.
2. Tests that are XFAILED or DISABLED but should not be.
We want to be able to build a target with just the platform-specific
libswiftRemoteMirror library. This should be a change in build logic
for existing presets but allows for a separate preset to be defined
that just builds the library if/when it's necessary.
- Add --build-swift-remote-mirror option to build-script-impl
- Add swift-remote-mirror known install component.
- Only add SwiftRemoteMirror targets if SWIFT_BUILD_REMOTE_MIRROR is on.
- Move libswiftRemoteMirror into the swift-remote-mirror install component.
- Add swift-remote-mirror install components to existing presets.
rdar://problem/27085666
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay`
arguments into `dynamic` and `static` variants, which makes the
following build command possible:
```
utils/build-script -- \
--build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \
--build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0
```
This command produces *only* static libraries for the stdlib, and no
SDK overlay libraries at all. Many other finely-grained build options
are now possible.
There are a couple of things going on in this patch. Lets consider first the
crosscompiling case.
In the cross compiling case, we were already setting LLVM_TOOLS_BINARY_DIR to
the binary dir of the just compiled LLVM (not the native LLVM/clang). This is
exactly what using LLVMConfig.cmake from that just compiled LLVM will set
LLVM_TOOLS_BINARY_DIR.
In the non-cross compiling case, we originally grabbed LLVM_TOOLS_BINARY_DIR
from llvm-config and then used that value to set the NATIVE llvm/clang paths.
rdar://26154980
Previously in order to support cross-compiling, we were setting these variables
in build-script. Now that we are using LLVMConfig.cmake, passing in these values
are no longer necessary. As an added benefit, Swift when not cross compiling,
does not need to set these variables anyways.
rdar://26154980
