Survey: How do you build Swift?

Development Standard Library
,
21

When I was doing unified builds, I was also directly using cmake and ninja, not using build-script. The SourceKit tests nonetheless did not work.

22

I'm close to BenL's configuration of "build-script to set up (and after LLVM+Clang updates), ninja / lit.py for day-to-day incremental work". My Ninja configuration is close to build-script -r but is spelled out in a preset as

[preset: ninja-build]
release-debuginfo
assertions
skip-build-benchmarks
build-subdir=ninja

and I have variations for when I need to build LLDB, or SwiftPM, or just want to rebuild LLVM without Swift.

I also have an Xcode build set up for editing purposes. It happens to have the configuration for a debug build of the compiler, so that if I need to do fine-grained compiler debugging I already have that set up, but I don't build it very often at all—just once every now and then to get the generated files to show up, so that code completion and Jump to Definition work. (They work very well almost all the time.)

[preset: xcode-build]
xcode
release-debuginfo
debug-swift
debug-swift-stdlib
assertions
skip-build-benchmarks
build-subdir=xcode
1 Like
23

Usually utils/build-script -R on macOS until I get it working. To confirm everything (or just try the latest) on Linux if I need Foundation/SwiftPM etc I started using utils/build-toolchain because otherwise the various things can't find stuff they require (libraries, binaries).

24

This is how I usually do it:

  1. I always start with a fresh install - I work on macOS - I usually (try to) work on the compiler itself
  2. I create a new directory to store Swift stuff
  3. git clone git@github.com:apple/swift.git into it
  4. ./swift/utils/update-checkout --clone-with-ssh (2x if something unexpectedly fails while checking out stuff :man_shrugging:)
  5. cd into the swift directory
  6. utils/build-script --debug --xcode and then open build/Xcode-DebugAssert/swift-macosx-x86_64/Swift.xcodeproj
  7. I try to do something useful :rainbow:
  8. utils/build-script --debug in preparation to run tests
  9. Testing: /complete/path/to/swift-source/llvm/utils/lit/lit.py --succinct --verbose /complete/path/to/swift-source/build/Ninja-DebugAssert/swift-macosx-x86_64/test-macosx-x86_64 --filter=<some filters for tests>

This is not the most optimised build process but I'm ok with that. It might actually be a good idea to use --release-debuginfo when building for tests with Ninja.

1 Like
25

I have flitted between different systems, but these days I just use Xcode. It used to be quite awkward to set up a decent Xcode environment, but I found @harlanhaskins and @codafi's talk to be very helpful and since then it's been fine.

The biggest thing that annoys me about building Swift these days, and perhaps is a bit of a turn-off for potential contributors, are the file sizes. My bin folder is >6GB, with lots of little tools that are each half a gig. Sometimes I notice that linking all of these things takes quite a while, so it would be nice if there was a way to optimise that. A Debug build of LLVM is also massive (~30GB), but I don't tend to edit it as much so I don't notice the link times.

bin folder

image
image758×1052 85.2 KB

2 Likes
26

I've never understood why the tools are separate binaries, both in LLVM and Swift. In addition to the senseless link time and disk usage, it creates an incentive not to package all the tools when packaging the compiler which can make debugging issues frustrating.

Should this be a bug report so we can move the discussion there?

27

I think there are two problems here: 1) local development and 2) deployment.

In the case of local development, the LLVM answer is "pass -DBUILD_SHARED_LIBS=TRUE to cmake". That being said, the Swift CMake files ignore this flag and fixing that means a lot of [possibly thankless] work disentangling circular dependencies between internal Swift libraries.

In the case of deployment, I think the reason why it hasn't been done already is that the naive POSIX solution is buggy because argv[0] is just an arbitrary string that happens to be the program name most of the time. The best POSIX workaround would be probably be to create tiny executable trampolines that re-exec a big shared executable with a trustworthy argv[0]. This, of course is avoidable if one can get at platform specific APIs, but at this point, someone is doing a lot of [possibly thankless] work.

28

I think we can append this advise from @codafi to this thread as it extends a little on how to proceed after building swift.

2 Likes
29

Just to follow up, I did an imprecise test and found that the build-script is about 75% slower than unified builds on my primary workstation.

1 Like