This have been disabled because they were flakey, but now we
should have fixed the issues (or if there's something outstanding,
well, it's the right time to fix).
This is getting more important as we want to increase the set
of `lit/` or `unittest`-style testcases.
The CMake build doesn't copy or symlink the system debugserver into its
local build when --lldb-use-system-debugserver is specified, nor should
it IMO. Instead, the CMake build's test targets explicitly specify the
server to use. Since we're not using one of those targets in
build-script, we should also specify the server explicitly.
- Side-step code signing issues by using the system debug server
- Skip testing categories that add minimal coverage-per-unit-time
- Only enable testing from the whitelisted `swiftpr` category
rdar://35534424
We can't use CMake to build lldb on the bots until the bots upgrade to
CMake >= 3.7: r://37130314.
In the past, we needed to disable building swift with -fmodules because
the module caching logic ignored sanitizer flags (rdar://28356072).
This is fixed now, so let's remove the workaround.
Other changes:
1) Minimize unified versus build-script build differences.
2) Stop trying to make runtime variables have "protected" visibility.
This combination is meaningless and lld rightly complains.
Finally, this blog post is worth reading:
http://www.airs.com/blog/archives/307
Also update how the variable is managed in the build system to allow the test to be conditional based on it, and make it more natural to set it on the command line.
This maybe was needed in the past, but we're moving to a model
where we really want to control what's failing and why. If something
fails, stop re-running. Instead, try to get a proper blame
mail and investigate. This might be a little shaky in the
short term but I'm confident it will go a long way.
Instead of building separately, they are now built together using a new workspace with new schemes.
As a result, xcodebuild is now invoked once per-platform, allowing for platform-specific build setting and architecture overrides.
This addresses <rdar://problem/36512531>.
These don't make sense to build separately, and indeed it's likely that PlaygroundLogger will soon depend on PlaygroundSupport.
As a result, build them as one product (playgroundsupport) in build-script.
Aside from removing the playgroundlogger product, this otherwise continues to build PlaygroundLogger and PlaygroundSupport the same way.
This is for <rdar://problem/36512531>.
As far as I can tell, this never worked, so removing it cannot break anything.
Now PlaygroundLogger is treated similarly to PlaygroundSupport, directly referencing xcodebuild instead of indirecting through variables.
This commit also introduces explicit error messages when attempting to build PlaygroundLogger or PlaygroundSupport for non-Darwin platforms.
This addresses <rdar://problem/36594779>.
build-script can already build lldb on Darwin using its Xcode project,
but it's useful to support the CMake build as well.
The CMake build allows incremental rebuilds with build-script. I expect
this to significantly cut down on iteration time.
Taking advantage of CMake also lets lldb piggyback on existing support
for sanitizers -- or exciting new build configurations we don't know
about yet -- without having to update the Xcode project file.
rdar://problem/36751944
Not all CMake configuration names are valid Xcode configurations at
the moment, but Xcode's "Release" still includes debug info, so it's
probably close enough.
I recently broke the out of tree build by mistake [its fixed now ; )]. This
inspired me to make it easy to test this behavior by adding support to
build-script/cmake/etc for running an external benchmark build via
AddExternalProjects.
Now I can just call build-script with --build-external-benchmarks and thats it!
It should just work! It already helped me to avoid breaking the external build
twice!
I hope that eventually we get this on a bot to make sure it keeps working [or
even added to the smoke tests ; )].
*NOTE* This is disabled by default so it will not affect normal builds.
*NOTE* This just builds the external benchmarks. There is an rpath issue that
prevents you from running them (the benchmarks have the rpath set as if they are
next to the stdlib, but they are not. This can be fixed in a few different ways,
but I do not have time to finish implementing it = (. But this commit is a good
first step and at least detects build errors.
Sometimes it's useful to be able to run tests located in specific
directories and/or files, let's enable this in `utils/build-script`
using `--test-paths` option which accepts a list of viable test locations.
Resolves: rdar://problem/32004487
The conversion was too aggressive and always forced the test and
installation of libdispatch. The CI system does not install libdispatch
and this broke the build.
- If --build-swift-static-stdlib option is used then also produce
static versions of libXCTest.a and libdispatch.a and put them
into the lib/swift_static/linux/ toolchain directory.
libFoundation.a is already being built and deployed there.
- Binaries with the swift libs statically linked in can then be
built with using the command:
swift build -Xswiftc -static-stdlib -Xlinker -lcurl -Xlinker -l:libxml2.a -Xlinker -llzma -Xlinker /lib/x86_64-linux-gnu/libz.so.1 -Xlinker -lbsd -Xlinker --allow-multiple-definition
Note: This is a dynamic binary with the libswiftCore,
libFoundation and libdispatch libraries statically linked in.
- Further fixes should reduce the complexity of the above command.
Before Swift 3.1, we installed the swift-stdlib-tool-substitute script
in place of Xcode's swift-stdlib-tool. This check was added to the build
script (76e99159c1) to avoid trying to strip that file. Now that
swift-stdlib-tool is part of open-source Swift, the -substitute script is
gone and there is no need for this check.
