-
Notifications
You must be signed in to change notification settings - Fork 10.6k
[SR-1738] Allow *only* static libraries to be built #3027
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
[SR-1738] Allow *only* static libraries to be built #3027
Conversation
|
@swift-ci please test |
b7e07fb to
b3997cb
Compare
|
@swift-ci please test |
|
@gribozavr This was a sort of work-in-progress, but I've updated it to something I think is good to go. It's based on the work from #3020 and #3043, so it'd be easier to review/merge those before looking at this. Let me know what you think -- thanks! |
|
Thank you! Would you mind rebasing and fixing the conflicts? |
b3997cb to
a1e7a87
Compare
|
Thanks @gribozavr. It's weird, though, this rebased cleanly onto master. I wonder if GitHub determines conflicts differently somehow... oh well! @swift-ci please test |
utils/build-script-impl
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we keep build-swift-stdlib and build-swift-sdk-overlay as aliases for --build-swift-static-xyz=1 --build-swift-dynamic-xyz=1? We are using these in build presets, would be best to not break them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gribozavr Done! I also updated the documentation in build-script-impl and the source code comments in CMakeLists.txt.
31cf9a8 to
144c270
Compare
|
@swift-ci please test |
|
Looks like the OS X build has stalled for the past 7 hours. Kicking it. @swift-ci please test |
|
@gribozavr OK! I think this is good to go. |
utils/build-script-impl
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Shouldn't it turn off the static one as well?
Also, would you mind moving the alias processing into Python? (Possibly in a future change.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add support for build-swift-sdk-overlay=0? Some of our internal presets use it.
|
Thank you! I'm running a few tests and I'll merge soon! |
|
@modocache Sorry, compatibility with |
144c270 to
bed9b45
Compare
|
@gribozavr OK, I've addressed your comments on both moving the logic into Python and on |
|
@swift-ci please test |
|
@gribozavr Is there a way to test the compatibility concerns you mentioned? @swift-ci consistently passes for me. Could you confirm whether this passes, and whether it can be merged? Sorry for all the pings 😅 |
|
Sorry, I was reviewing other patches. I'm running a test locally now. |
|
@modocache Sorry, this change does not yet fix the issue. The command that we care about is: It should not build the overlay at all. |
utils/build-script
Outdated
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could you add an else clause that sets both to False?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't that overwrite whatever was passed to --build-swift-dynamic-stdlib and --build-swift-static-stdlib? For example, consider the following invocation:
utils/build-script --build-swift-static-stdlib=1
Since --build-swift-stdlib is not passed in, the else statement would be executed, which would set --build-swift-static-stdlib=0, thus negating the desired invocation. Or am I missing something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You're right. We probably want it to be a tristate then. If --build-swift-stdlib is not passed on the command line, do nothing, if it is passed, then it should override other args.
Once this PR is merged, I'll try to remove the uses of legacy parameters internally.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is there a good way to determine whether --build-swift-stdlib is specified on the command line? Right now it seems like the following are indistinguishable:
$ utils/build-script
$ utils/build-script --build-swift-stdlib=0
Is there a good way to distinguish these two using the existing swift_build_support code? Or should I make some modifications there, or just inspect argv?
Thanks for all your help!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's a way, but we'd need to stop using the optional_bool action. Since this is a short-lived compatibility aid, I think inspecting argv is acceptable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think action=optional_bool, default=None will have 3 possible state.
(is None, True, False).
Not confirmed though.
Confirmed, works as expected:
parser.add_argument(
"--my-opt", action=arguments.action.optional_bool, default=None)
args = parse_args( ... )
if args.my_opt is None:
print("DEFAULT")
elif args.my_opt:
print("YES")
else:
print("NO")There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Perfect, this is just what I need. Thanks, @rintaro!! I'll make the changes first thing tomorrow.
This splits the `--build-swift-stdlib` and `--build-swift-sdk-overlay` arguments into `dynamic` and `static` variants, which makes the following build command possible: ``` utils/build-script -- \ --build-swift-dynamic-stdlib=0 --build-swift-dynamic-sdk-overlay=0 \ --build-swift-static-stdlib=1 --build-swift-static-sdk-overlay=0 ``` This command produces *only* static libraries for the stdlib, and no SDK overlay libraries at all. Many other finely-grained build options are now possible.
bed9b45 to
f12a132
Compare
|
@gribozavr OK, I addressed your comments, thanks to @rintaro's suggestion. Please have another look! I'd love to merge this before the weekend. 😎 ☀️ @swift-ci please test |
|
@modocache Thank you, my tests pass now! Please merge when the CI succeeds! |
|
Thanks a ton, @gribozavr! 🙇 |
What's in this pull request?
This splits the
--build-swift-stdliband--build-swift-sdk-overlayarguments intodynamicandstaticvariants, which makes the following build command possible:This command produces only static libraries for the stdlib, and no SDK overlay libraries at all. Many other finely-grained build options are now possible.
@gribozavr This pull request is built on top of #3020 and #3043; it'll be easier to review and merge those first. Thanks for all your feedback on this! 🙇
Resolved bug number: (SR-1738)
Before merging this pull request to apple/swift repository:
Triggering Swift CI
The swift-ci is triggered by writing a comment on this PR addressed to the GitHub user @swift-ci. Different tests will run depending on the specific comment that you use. The currently available comments are:
Smoke Testing
Validation Testing
Lint Testing
Note: Only members of the Apple organization can trigger swift-ci.