Skip to content

[Build Script Helper] On macOS make install action use CMake and install libSwiftDriver #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 6 commits into from
Sep 29, 2020

Conversation

artemcm
Copy link
Contributor

@artemcm artemcm commented Sep 11, 2020

Previously only the x86 swift-driver and swift-help executables were copied over to the specified toolchain's bin directory.
With this change, libSwiftDriver shared library is also packaged and installed into the toolchain, as well as libSwiftOptions.
To do so, we build the driver and all of its dependencies using CMake for arm64 and x86_64 and create universal binaries, as documented here.

Because the driver's dependencies need to come along for the ride, the installed artifacts are as follows, within the specified toolchain:

Executables:

bin/swift-driver
bin/swift-help

Binary Modules and Shared Libraries

lib/swift/macosx/libTSCBasic.dylib
lib/swift/macosx/libTSCLibc.dylib
lib/swift/macosx/libTSCUtility.dylib
lib/swift/macosx/libSwiftDriver.dylib
lib/swift/macosx/libSwiftOptions.dylib

lib/swift/macosx/TSCBasic.swiftmodule
lib/swift/macosx/TSCLibc.swiftmodule
lib/swift/macosx/TSCUtility.swiftmodule
lib/swift/macosx/SwiftDriver.swiftmodule
lib/swift/macosx/SwiftOptions.swiftmodule

C Module .modulemap and header files

include/swift/TSCclibc/*

Misc

  • The Yams dependency is implementationOnly and is built as a static-library.
  • ArgumentParser.swiftmodule and libArgumentParser.dylib must also be installed into the toolchain, but the code currently omits them, to avoid adding them to the toolchain until they are actually needed.

Resolves rdar://69708243

@artemcm
Copy link
Contributor Author

artemcm commented Sep 15, 2020

Two blockers for this, currently:

  • Building swift-driver with library-evolution enabled fails because the compiler prints unqualified types for type extensions to the interface file and we are extending TSCBasic.Process, which is ambiguous with Foundation.Process. Brent has a fix PR to make the compiler print qualified extension type names here: Qualify the names of extended types in module interfaces swift#32780, but just throwing this fix in I am seeing other failures. More investigation needed.
  • Without library-evolution, the installation works for me locally, but does not work in Swift CI (e.g. here: [Build Script] Pass down a CMake path to swift-driver's build script swift#33918) because when building LLBuild, my local build figures out to use Xcode SDK's version of libSQLite, whereas in CI, the build uses the one in /usr/local/lib/, which only has an x86_64 slice so the arm64 build fails.

@artemcm artemcm force-pushed the install_libSwiftDriver branch from 66906bd to 693b1ba Compare September 15, 2020 20:53
@nkcsgexi
Copy link
Contributor

@artemcm Just discussed @DougGregor about this, we could first disable -enable-library-evolution for now and use the binary module format for submission. The build system can link against libSwiftDriver in the default toolchain so we could start experimenting with the explicit module feature. Multiplexing libSwiftDriver can be a concern we tackle some point later.

@artemcm
Copy link
Contributor Author

artemcm commented Sep 15, 2020

@artemcm Just discussed @DougGregor about this, we could first disable -enable-library-evolution for now and use the binary module format for submission. The build system can link against libSwiftDriver in the default toolchain so we could start experimenting with the explicit module feature. Multiplexing libSwiftDriver can be a concern we tackle some point later.

Sounds good! I'll push through with resolving the remaining issues without using -enable-library-evolution.

@nkcsgexi
Copy link
Contributor

@artemcm Just discussed @DougGregor about this, we could first disable -enable-library-evolution for now and use the binary module format for submission. The build system can link against libSwiftDriver in the default toolchain so we could start experimenting with the explicit module feature. Multiplexing libSwiftDriver can be a concern we tackle some point later.

Sounds good! I'll push through with resolving the remaining issues without using -enable-library-evolution.

Thank you!

@artemcm artemcm force-pushed the install_libSwiftDriver branch from 268d83c to daef6f4 Compare September 16, 2020 23:33
@artemcm artemcm changed the title [WIP][Build Script Helper] On macOS make install action use CMake and install libSwiftDriver [Build Script Helper] On macOS make install action use CMake and install libSwiftDriver Sep 17, 2020
@artemcm
Copy link
Contributor Author

artemcm commented Sep 17, 2020

This is currently functional (I can build a simple swift program that imports and uses SwiftDriver by pointing library and include paths to the built toolchain).
In our chat, @nkcsgexi brought up a good point that we should probably be able to refactor SwiftDriver into a client library for build systems that does not itself depend on llbuild. We can do this refactoring as either a follow-up or a pre-requisite to this change.

@artemcm artemcm force-pushed the install_libSwiftDriver branch 2 times, most recently from 3467290 to 645f15d Compare September 17, 2020 18:22
@artemcm artemcm marked this pull request as ready for review September 17, 2020 18:23
@artemcm
Copy link
Contributor Author

artemcm commented Sep 18, 2020

@swift-ci please test

1 similar comment
@artemcm
Copy link
Contributor Author

artemcm commented Sep 18, 2020

@swift-ci please test

@artemcm
Copy link
Contributor Author

artemcm commented Sep 18, 2020

Note: This must be merged in tandem with: swiftlang/swift#33918

… install libSwiftDriver

Previously only the x86 `swift-driver` and `swift-help` executables were copied over to the specified toolchain's `bin` directory.
With this change, libSwiftDriver shared library is also packaged and installed into the toolchain, as well as libSwiftOptions.
To do so, we must build SwiftDriver and all of its dependencies using CMake for arm64 and x86_64 and create universal binaries, as documented here:
https://developer.apple.com/documentation/xcode/building_a_universal_macos_binary
…ad of static

It is shared by SwiftDriver and SwiftOptions and building it as a static lib causes them to have common symbols.
This does mean that we have to isntall TSC libraries into the toolchain as well
…hain, until needed

Code commented-out with TODOs
@artemcm artemcm force-pushed the install_libSwiftDriver branch from 645f15d to 0a46481 Compare September 24, 2020 16:04
@artemcm
Copy link
Contributor Author

artemcm commented Sep 24, 2020

@swift-ci please test

@artemcm artemcm changed the base branch from master to main September 24, 2020 17:02
@artemcm
Copy link
Contributor Author

artemcm commented Sep 24, 2020

@swift-ci please test

Copy link
Member

@DougGregor DougGregor left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all looks reasonable to me. Thank you!

@artemcm artemcm force-pushed the install_libSwiftDriver branch from 0a46481 to 9d43e33 Compare September 25, 2020 15:03
@artemcm
Copy link
Contributor Author

artemcm commented Sep 25, 2020

@swift-ci please test

2 similar comments
@artemcm
Copy link
Contributor Author

artemcm commented Sep 28, 2020

@swift-ci please test

@artemcm
Copy link
Contributor Author

artemcm commented Sep 28, 2020

@swift-ci please test

@artemcm artemcm merged commit 0402b40 into swiftlang:main Sep 29, 2020
@artemcm artemcm deleted the install_libSwiftDriver branch January 20, 2021 19:01
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants