Skip to content
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] [CMake] add_swift_library should take explicit SHARED/STATIC argument #44347

Closed
modocache mannequin opened this issue Jun 13, 2016 · 5 comments
Closed

[SR-1738] [CMake] add_swift_library should take explicit SHARED/STATIC argument #44347

modocache mannequin opened this issue Jun 13, 2016 · 5 comments
Assignees

Comments

@modocache
Copy link
Mannequin

modocache mannequin commented Jun 13, 2016

Previous ID SR-1738
Radar None
Original Reporter @modocache
Type Improvement
Status Closed
Resolution Done
Additional Detail from JIRA
Votes 0
Component/s Project Infrastructure
Labels Improvement
Assignee @modocache
Priority Medium

md5: e92548e5df1c13595118c9d4fae7afd2

Issue Description:

As @gribozavr writes on the discussion on #2431

> I'm also thinking about changing the add_swift_library function to get an explicit annotation about the library: whether it is only shared, only static, or defers to the general stdlib policy. For example, we want libswiftReflection to always be static, and libswiftRemoteMirror to always be shared, so that libswiftRemoteMirror.dylib does not have other runtime dependencies.

> The primary issue is that currently the CMake code is not set up around static/shared libraries; it builds a "primary" one (which is usually static for compiler components and shared for the standard library), and then it can build a secondary one, which is static for the standard library. I have started that work with #2809 but we're not done yet.

Making this improvement would also make it easier to build the feature from #2431 the ability to build only static versions of the static libraries.

@modocache
Copy link
Mannequin Author

modocache mannequin commented Jun 13, 2016

Currently, callers of add_swift_library provide a SHARED parameter (or specify IS_SDK_OVERLAY) to build a shared library, or provide nothing to build a static library. Various parts of the CMake build system then use the SWIFT_BUILD_STATIC_STDLIB global to determine whether to also build libraries marked as IS_SDK statically.

I think the initial change to make here is to instead require callers pass in SHARED or STATIC (or both) to add_swift_library. Ideally, SWIFT_BUILD_STATIC_STDLIB would only be used to determine whether calls to add_swift_library for the stdlib are passed STATIC.

@modocache
Copy link
Mannequin Author

modocache mannequin commented Jun 13, 2016

I thought the only two options were STATIC or SHARED, but there's also MODULE and OBJECT_LIBRARY. Should add_swift_library take these as parameters as well? @gribozavr

@gribozavr
Copy link
Collaborator

We are using OBJECT_LIBRARY now, and not using MODULE.

@modocache
Copy link
Mannequin Author

modocache mannequin commented Jun 14, 2016

First step: all callers now pass in STATIC, SHARED, or OBJECT_LIBRARY: #3020

I think the next step is to clean up add_swift_library a bit: instead of using IS_SDK, IS_SDK_OVERLAY and SWIFT_BUILD_STATIC_STDLIB, use only the STATIC and SHARED parameters to determine how to name the library targets:

  • When only one of STATIC or SHARED is specified, the added target is target_name.

  • When both STATIC and SHARED are specified, target_name and target_name-static are added.

As usual, feedback is welcome. Let me know if my approach seems off here.

@modocache
Copy link
Mannequin Author

modocache mannequin commented Dec 4, 2016

I resolved this in #3027

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant