Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # 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
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants