Thanks! Looks good but we also need to modify Dune_file.Library.to_lib_info, in particular the foreign_archives field. We should probably factorise the logic for deciding about whether the library has an archive in one place.

Hmm - I can see the problem, but I'm not sure how to proceed. The list of modules in the library isn't determined at the point the Lib_info.t is assembled? It sounds as though the decision on whether there's going to be a .a or .lib file needs to be deferred, right?

This also needs a CHANGES entry

We can always use Dir_contents.modules_of_library to determine that. We probably can't do it inside dune_file.ml, but we can do it from lib.ml where to_lib_info is called

This has been worked around in stdlib-shims, so it's no longer a blocker for Dune 1.11.4.

The full solution will require refactoring the use of the foreign_archives field to be a function - at the moment there's a circular dependency because you can't determine the foreign_archives without scanning the directory and you can't scan the directory until you've built the super-context which involves calculating the foreign_archives field!

The workaround for now is to remove the .lib file from foreign_archives if the modules stanza is explicitly empty. This is obviously not ideal (although it does fix the stdlib-shims use case). To this end, I've added a note to implement a warning in the install rule if the library is found to have no modules but the modules stanza was not explicitly empty - the idea is that Dune will either warn that the rule is not portable or, for MSVC, fail with an error (because dune-package will contain incorrect information).

Note that the fix in stdlib-shims is constrained to < 4.10.0, so either this has to be fixed before OCaml 4.10 comes out, or the shim needs updating again.

Re-created in #2829