Skip to content

[TBDGen] Allow user-provided dylib version flags #18716

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 4 commits into from
Aug 15, 2018

Conversation

harlanhaskins
Copy link
Contributor

@harlanhaskins harlanhaskins commented Aug 15, 2018

This patch adds two frontend arguments, -tbd-compatibility-version and
-tbd-current-version, both of which accept SemVer versions.

These will show up in the generated TBD file for a given module as

current-version: 2.7
compatibility-version: 2.0

These flags both default to 1.0.0, and TAPI will not write them in the .tbd file if they're 1.

Resolves: rdar://34560882

This patch adds two frontend arguments, -tbd-compatibility-version and
-tbd-current-version, both of which accept SemVer versions.

These will show up in the generated TBD file for a given module as

current-version: 2.7
compatibility-version: 2.0

These flags both default to `1.0.0`.
@harlanhaskins
Copy link
Contributor Author

@swift-ci please smoke test

@CodaFi
Copy link
Contributor

CodaFi commented Aug 15, 2018

What breaks if the user doesn't specify these flags when emitting TBD files?

@harlanhaskins
Copy link
Contributor Author

Nothing ‘breaks’, per se, they just each default to 1. This is undesirable as the TBD file will not match a generated file in which the DYLIB_CURRENT_VERSION and/or DYLIB_COMPATIBILITY_VERSION build settings are overridden.

version::Version TBDCurrentVersion = {1, 0, 0};

// The dylib compatibility-version to use in the generated TBD file.
version::Version TBDCompatibilityVersion = {1, 0, 0};
Copy link
Contributor

Choose a reason for hiding this comment

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

I think we're going to want to just prepopulate TBDGenOptions soon, like we do with IRGenOptions, rather than pass everything through FrontendOptions. What do you think? (Probably for a follow-up, not here.)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Yeah, that sounds good. I'll submit that cleanup in a follow-up patch.

// RUN: %empty-directory(%t)
// RUN: %target-swift-frontend -emit-ir -o /dev/null %s -tbd-current-version 2.0.3 -tbd-compatibility-version 1.7 -emit-tbd -emit-tbd-path %t/both_provided.tbd
// RUN: %target-swift-frontend -emit-ir -o /dev/null %s -tbd-current-version 2.0 -emit-tbd -emit-tbd-path %t/only_current_provided.tbd
// RUN: %target-swift-frontend -emit-ir -o /dev/null %s -tbd-compatibility-version 2 -emit-tbd -emit-tbd-path %t/only_compat_provided.tbd
Copy link
Contributor

Choose a reason for hiding this comment

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

Can you add a test case for something that doesn't parse, to be sure that it produces a diagnostic?

@harlanhaskins
Copy link
Contributor Author

@swift-ci please smoke test

@harlanhaskins harlanhaskins merged commit 7318efe into swiftlang:master Aug 15, 2018
@harlanhaskins harlanhaskins deleted the linked-and-loaded branch August 15, 2018 18:42
harlanhaskins pushed a commit to harlanhaskins/swift that referenced this pull request Sep 7, 2018
* [TBDGen] Allow user-provided dylib version flags

This patch adds two frontend arguments, -tbd-compatibility-version and
-tbd-current-version, both of which accept SemVer versions.

These will show up in the generated TBD file for a given module as

current-version: 2.7
compatibility-version: 2.0

These flags both default to `1.0.0`.

* Reword some comments

* Add test for invalid version string

* Expand on comments for TBD flags
harlanhaskins pushed a commit to harlanhaskins/swift that referenced this pull request Sep 12, 2018
* [TBDGen] Allow user-provided dylib version flags

This patch adds two frontend arguments, -tbd-compatibility-version and
-tbd-current-version, both of which accept SemVer versions.

These will show up in the generated TBD file for a given module as

current-version: 2.7
compatibility-version: 2.0

These flags both default to `1.0.0`.

* Reword some comments

* Add test for invalid version string

* Expand on comments for TBD flags
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.

3 participants