I just learned via build: extract libdispatch build for swift by compnerd · Pull Request #18500 · apple/swift · GitHub that Foundation and libdispatch are about to be hard dependencies for Swift proper. This is unfortunate. I'd really like to keep the door open to Swift being used in low-level contexts where Foundation and/or libdispatch would be a deal breaker. Is there any room for appeal? Also, did I miss an announcement somewhere? Was this debated anywhere?
6 Likes
No, we never discussed or decided this. I'm not sure where that notion came from. It looks like Ted already reverted the patch.
Yes, I consider this a major policy change that needs to be discussed. It's a major violation of the layering of the project. I am not supportive of this change at this time.
7 Likes
Thanks Ted – I feared I missed some communication.
2 Likes
I believe that in swift 5.4 and 5.5 there is a hard dependency on libdispatch that wasn't there up to 5.3.
I believe it has to do with concurrency and swift test lib. Also, the folder test/Concurrency is new to 5.4 and is present in 5.5.
I tried to build swift on openbsd by following the openbsd instructions and it fails for 5.4 and 5.5 because of not having libdispatch.
I managed to build 5.3.
Had a quick look at the build system for 5.5 trying to make it build without errors and it looks like dispatch is a dependency.
1 Like
Check out this doc pull by the guy who has been porting Swift to OpenBSD, which shows how to build for OpenBSD with the new concurrency library disabled. Alternately, you could apply his libdispatch pull linked there and see if that gets it all working.
1 Like
These look very interesting. I am going to check them soon, thanks a lot for sharing them 
However, the base question of the original post still remains: is dispatch a hard dependency now?
It's not only about openbsd, which I am very happy to see that is gaining support, it's also about smaller embedded systems for example...
The original issue was fixed very quickly after it was reported. Assuming that your build is setup correctly, then libdispatch and Foundation are still optional.
What do you mean "Assuming that your build is setup correctly" ? I am following the instructions that I am seeing on swift.org, GitHub and the specific OpenBSD page.
dispatch does not seem to be optional in a default build anymore.
This is what I am finding out. Even in the updated instructions for OpenBSD in the link that @Finagolfin shared, assuming they work which is what I am trying now, one has to explicitly disable dispatch with these:
-DSWIFT_ENABLE_DISPATCH=OFF,\
-DSWIFT_BUILD_SOURCEKIT=OFF,\
-DSWIFT_BUILD_SYNTAXPARSERLIB=OFF,\
-DSWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY=OFF,\
-DSWIFT_IMPLICIT_CONCURRENCY_IMPORT=OFF,\
-DSWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED=OFF,\
If you want a supported build setup, then libdispatch probably is required. That being said, there exists unsupported build setups that can disable libdispatch. I can't speak for whether build-script (the supported way to build Swift) allows disabling libdispatch, but what I can speak to is using cmake directly. I configure swift directly with cmake so at that level of the project, I am able to disable libdispatch.
That's VERY interesting
Would you be willing to share the cmake options that you use to build swift directly? Or is there any link you can share that teaches how to get started with that?
I'm sorry. I don't think there is any link that I know of. I basically have a ultra-minimal Swift setup where Swift (and cmark) are built as LLVM "external projects" via one big cmark/ninja build. I don't remember which is best, but something like the following passed to LLVM's cmake pass:
-DLLVM_EXTERNAL_SWIFT_SOURCE_DIR=...path/to/swift -DLLVM_EXTERNAL_CMARK_SOURCE_DIR=...path/to/cmark
Alternatively, just dump swift and cmark into your checkout of llvm-project and then add swift and cmark to -DLLVM_ENABLE_PROJECTS=...
From there you should be able to just type ninja check-swift and then all of llvm/clang/cmark and swift will build concurrently and then the test suite will run. Good luck.
However, the base question of the original post still remains: is dispatch a hard dependency now?
It is a dependency of two host libraries, Sourcekit and SyntaxParser, and one target library, the new Concurrency runtime, which uses dispatch as its default executor. There is a plan to support custom executors for Concurrency, with some early support for swapping dispatch out.
Since you can always build and use Swift without those two host tools and either not using the brand new concurrency runtime or eventually swapping in a different executor, I'd say dispatch is a soft dependency.
1 Like
You can build the concurrency runtime to not have Dispatch as a dependency, either by telling Swift to use a single-threaded runtime or by telling Swift to maintain multi-threaded support but also not to call into Dispatch. In the latter case, you will need to hook into the runtime dynamically to provide your own global concurrent executor (such as a thread pool), or else the relevant code will simply abort.
4 Likes
What I mean is that I believe that there is an unwanted dispatch dependency that creeped in into StdlibUnittest.
When I start building swift ( after llvm and cmark ) using utils/build-script and the options for openbsd ( even the new ones that you mentioned ) I get that the makefile complains about not having libdispatch and I did not find an option to remove that dependency or to skip building stdlib unittest.
I understand that this can be adjusted by building swift and cmark as llvm subprojects as suggested by @DaveZ.
Is it possible with utils/build-script?
What I mean is that I believe that there is an unwanted dispatch dependency that creeped in into StdlibUnittest.
I don't see anything, what is the error you get? If you're applying those build flags to avoid using libdispatch, the build shouldn't be pulling it in.
Hello!
One thing to check is that the CMakeCache file variables are being set correctly. Sometimes, the flags aren't split correctly (depending on shell perhaps?) and may spill together. If need be, ensure each flag is separated by spaces without the commas.
If you're still having trouble, let me know what exact errors you are getting and I can investigate further.
Hi
it looks like there is another issue now.
something else came up: I am building on openbsd 7.0, freshly downloaded source, with the llvm stable/20210726 branch as suggested in the patch for 7.0 and get an error when linking llvm-lto.
I never had any problem with building llvm before. Are you sure that that is the branch to be used?
I don't know what the exact error you are getting but I am guessing it might be the one addressed by this part of the doc:
For debug builds especially, consider also installing the llvm package and setting -DCMAKE_AR=/usr/local/bin/llvm-ar and -DCMAKE_RANLIB=/usr/local/bin/llvm-ranlib with the extra-cmake-options flag, to work around problems creating indexes to archives containing object files with large numbers of section headers.
I think that the doc isn't quite clear enough that the build-script command as written gives you a debug build by default (and therefore these flags are more necessary). You have two options: build Swift as release, or add these. I'll update the pr.
Thanks 
I will check that. In fact I had tried it before with those options on and with Release build type and in every case llvm was built correctly
After I have dealt with llvm, I'll come back with the results from trying to build swift.
Sorry if it takes me a long time to go through this. I am doing these builds at night while I sleep