I've hit a number of issues trying to package `fmt` for `build2` with modules support. - A couple of I think recent regressions, [addressed in this PR](https://github.com/fmtlib/fmt/pull/4152). - `fmt.cc` with `import std;` disabled will `#include <expected>` without any of the guards used for including it inside `fmt/std.h`, which raises a warning on MSVC. I haven't addressed this in the PR as `FMT_HAS_INCLUDE` isn't available at that point in the source file, and I'm also unsure why the C++ version and above macro are used in some places but feature test macros in others. - I guess the `fmt` modules support is not being verified by the CI? I'm also a bit unclear on what the status is of the tests wrt modules. I can see there is a `module-test.cc`, but before that gets added in the cmake file [this check](https://github.com/fmtlib/fmt/blob/master/test/CMakeLists.txt#L46-L48) will bail out. There appear to also be issues with the combination of modules and shared builds. - I've hit issues with the symbol export macros, however there are some unanswered questions here about what `build2` should be doing, so it's not clear to me yet if anything will need to change on the `fmt` side for this particular problem. - Even if I work around the above, I end up with lots of linker errors about undefined symbols when building the tests against a shared modules build of the library (example output attached). I believe these derive from the fact that inside a module TU, member functions defined within the class definition are not implicitly `inline` as they are in traditional TUs. As such there are lots of functions that have not been marked as `FMT_API` (themselves or via their class) as they were implicitly inline; but now in the modules case they no longer are. There would appear to be two options: mark more classes/functions as `FMT_API`, or mark the member functions as explicitly inline. I wonder if the former can potentially cause problems for a non-modules build, but I'm generally unsure of the trade-offs here. [clang-libcpp-fedora-modules-link-errors.txt](https://github.com/user-attachments/files/16861655/clang-libcpp-fedora-modules-link-errors.txt)