On Wed, Dec 13, 2023 at 07:17:16AM +0000, Olga Arkhipova via SG15 wrote:
> Thanks, Daniel, for writing all this down.
>
> Looks like there is not much difference between library manifest and module metadata currently. So I think it should not be much harm in threat it as a library manifest v0, we can always ignore fields later if we decide otherwise.
>
> If we do it as a library manifest, we have to have the library name there.
> Besides being useful in diagnostic messages and output location (and we do use it in current MS implementation), it is needed to allow future library reference resolution. At least on Windows the location of the manifest does not give any information about the library it represents, so we need it in the manifest itself.
>
> The library name has to be unique to allow unambiguous referencing in other libraries. I don’t know if there are other libraries in the world which provide the same functionality besides STL, but to allow the replacement, we should also have something like “library-type” or “library-common-name” – something similar to is-std-library, but more generic. For std libs it will be set to “std” so referencing libraries can just use “std” if they allow the substitution. I also think that this Is a library and not a module attribute, but if there are some nuances I am not aware of, we can sure have additional attributes for each module overriding the general library one.
>
> So, to make it visual, I am proposing to have
>
> {
> "version": 1,
> "revision": 0,
> “library”: “unique name like Microsoft.STL",
> “library-common-name”:”std”
> "c++": {
> "modules": []
> }
> “referenced-libraries”:[] <-- not present for std libs, but other libraries can reference “std” and other libs.

I wonder MSVC STL's std.compat module imports and exports the std
module. Should this dependency be listed here. (In libc++ I don't do
that yet since the dependencies don't work properly yet.)

Mark