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

Feature/attach to gmf #3387

Merged
merged 1 commit into from
Apr 23, 2023
Merged

Feature/attach to gmf #3387

merged 1 commit into from
Apr 23, 2023

Conversation

DanielaE
Copy link
Contributor

No description provided.

@vitaut
Copy link
Contributor

vitaut commented Apr 17, 2023

This overlaps with #3386. Did you mean to include only the first commit in this PR?

@DanielaE
Copy link
Contributor Author

I pushed only the second as a PR from the Github UI. I.e. the changes to fmt.cc.

@vitaut
Copy link
Contributor

vitaut commented Apr 18, 2023

Please rebase.

@DanielaE DanielaE force-pushed the feature/attach-to-gmf branch from d4dcf38 to 56d0049 Compare April 18, 2023 14:56
@DanielaE
Copy link
Contributor Author

Done.

@vitaut
Copy link
Contributor

vitaut commented Apr 19, 2023

Please provide some details why this change is needed.

@DanielaE
Copy link
Contributor Author

If you build {fmt} as a module, you're basically compiling it as a static library that happens to export its interface in a binary form called BMI. All declarations and definitions are attached to to the module, all signatures and symbols carry an additional part that says so. In msvc this is a suffix <!fmt>, clang and gcc have something similar now that they both are following msvc's example and have switched over to the so-called 'strong module ownership' model.

Suppose you have a program in transition: parts are using {fmt} in module form, the rest is still using it through #includes. This means you have one set of declarations and symbols (all of them!) attached to the module, and another, additional set (brought in by the #includes) attached to the so-called global module. Both can coexist in the same program because their signatures and symbols are different. But you pay for all those duplications.

If you define macro FMT_ATTACH_TO_GLOBAL_MODULE, all declarations are subjected to explicit language linkage specification "extern C++". This detaches them from the module, the additional symbol name parts don't exist and the module behaves like a static library build in the traditional sense. The private module partition provides all the definitions of entitites declared out-of-line.

@DanielaE
Copy link
Contributor Author

I have this feature in my Asio module to support exactly this kind of scenario.

@vitaut
Copy link
Contributor

vitaut commented Apr 22, 2023

Makes sense, thanks for the explanation. Please add a short comment clarifying this before the FMT_ATTACH_TO_GLOBAL_MODULE check.

src/fmt.cc Outdated
Comment on lines 74 to 75
// All library-provided declarations and definitions must be in the module
// purview to be exported.
Copy link
Contributor

Choose a reason for hiding this comment

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

It looks like this comment applies to FMT_ATTACH_TO_GLOBAL_MODULE which is not right. Should it be moved some place else?

…dule fmt`

This allows coexistence with TUs that use {fmt} through #include without duplicating declarations, definitions, linker symbols, and object code.
@DanielaE DanielaE force-pushed the feature/attach-to-gmf branch from 56d0049 to 17ce9f7 Compare April 23, 2023 07:58
@vitaut vitaut merged commit eafcd3c into fmtlib:master Apr 23, 2023
@vitaut
Copy link
Contributor

vitaut commented Apr 23, 2023

Merged, thanks!

@DanielaE DanielaE deleted the feature/attach-to-gmf branch April 23, 2023 13:45
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.

2 participants