* LLDB assertions are on by default, like swift assertions
* LLDB assertions can be enabled/disabled globally with the --assertions
and --no-assertions options
Partially addresses: rdar://38524846
The lldb bots should run the full lldb test suite, not just the tests
reserved for pull-request testing.
This does not affect PR testing.
rdar://38462589
This adds two flags to the build script to enable/disable assertions in
llbuild: --llbuild-assertions, --no-llbuild-assertions
The default value is taken from the global assertions flag.
The CMake support in llbuild is finding the compiler in the system
instead of the build products. This causes build errors if Swift is old
on a system.
This is needed to support cross-compilation on targets which do not
support FAT binaries (i.e. non-MachO targets). The primary user of this
functionality right now is Windows, but this support is needed for Linux
and android as well.
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
