Skip to content

dispatch: split DISPATCH_EXPORT and prepare for static linking #872

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

compnerd
Copy link
Member

This change accomplishes two items:

  1. splits out a new DISPATCH_EXTERN macro to decorate with extern or extern "C" based on the compilation mode (C vs C++).
  2. enables a new configuration macro (dispatch_STATIC) that allows building with libdispatch for static linking. The default remains dynamic linking.

The motivation for DISPATCH_EXTERN is primarily being able to concisely define DISPATCH_EXPORT. This follows the naming scheme that most other Apple frameworks use (e.g. UIKit, Foundation, etc).

The change to introduce support for static linking is motivated by Windows. With the gradual roll out of static linking of the runtime, it would be convenient to be able to statically link dispatch into a fully sealed Swift program. Doing so requires building libdispatch without the __declspec(dllexport) and __declspec(dllimport) attributes on Windows. Similarly, it would be unfortunate to have dispatch's ABI be subsumed by a client library and have it participate in dynamic linking.

The user is responsible for defining dispatch_STATIC when using a static copy of libdispatch. This allows the default to remain dynamic linking (which is the preferred style on Darwin and Windows).

This change accomplishes two items:
1. splits out a new `DISPATCH_EXTERN` macro to decorate with `extern` or
   `extern "C"` based on the compilation mode (C vs C++).
2. enables a new configuration macro (`dispatch_STATIC`) that allows
   building with libdispatch for static linking. The default remains
   dynamic linking.

The motivation for `DISPATCH_EXTERN` is primarily being able to
concisely define `DISPATCH_EXPORT`. This follows the naming scheme that
most other Apple frameworks use (e.g. UIKit, Foundation, etc).

The change to introduce support for static linking is motivated by
Windows. With the gradual roll out of static linking of the runtime, it
would be convenient to be able to statically link dispatch into a fully
sealed Swift program. Doing so requires building libdispatch without the
`__declspec(dllexport)` and `__declspec(dllimport)` attributes on
Windows. Similarly, it would be unfortunate to have dispatch's ABI be
subsumed by a client library and have it participate in dynamic linking.

The user is responsible for defining `dispatch_STATIC` when using a
static copy of libdispatch. This allows the default to remain dynamic
linking (which is the preferred style on Darwin and Windows).
@compnerd
Copy link
Member Author

@swift-ci please test

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.

1 participant