Interesting. Useful. Thanks.
It looks like your patch is powershell script so probably not directly what I’d use on macOS. But still gives me ideas. And I saw your review comment reply that building shared dynamic libraries for the compiler parts instead of standalone executables (depending only on platform DLLs) probably isn’t very useful, because binary size isn’t that important on the actual compiler tools themselves. I felt the same, the change was relatively recent I think (although I lose track a bit as I was in a fairly isolated corner with my product), and it didn’t really seem necessary to me when I saw it. Though I am only just now upgrading my toolchains to use the new swift-driver, so I’m not a very useful source of opinion!
For now I went with a very simple point patch on my swift-driver tree. This wouldn’t be suitable for upstreaming at all, I’d parameterise it to scale it, add tests, etc. if it were “real” swift compiler work of course…
diff --git a/Utilities/build-script-helper.py b/Utilities/build-script-helper.py
index ee161000..30a964c3 100755
--- a/Utilities/build-script-helper.py
+++ b/Utilities/build-script-helper.py
@@ -420,7 +420,7 @@ def build_using_cmake(args, toolchain_bin, build_dir, targets):
base_swift_flags.append('-module-cache-path "{}"'.format(os.path.join(build_dir, 'module-cache')))
for target in targets:
- base_cmake_flags = []
+ base_cmake_flags = ['-DBUILD_SHARED_LIBS=NO']
swift_flags = base_swift_flags.copy()
swift_flags.append('-target %s' % target)
if '-apple-macosx' in args.build_target:
Thank you for your help and advice guys.