>>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.)

Currently, we don't require the dependencies to be listed in the module.json file. As we are dealing with the sources (not BMIs) and will scan them (as other modules), we'll discover the dependencies automatically. Also, maintaining the dependencies for a complex "source only" library can be quite challenging, so I don't think we should ever require it. For BMIs it is a different story.

But the build needs to know the names of the library modules without scanning their sources as otherwise it will have to always scan all available library modules, even if none are used in the user's code.
The module names seem to be easy for library authors to list/maintain in the json with their source files and this is what we are currently proposing to have there.

Olga

-----Original Message-----
From: Mark de Wever <koraq_at_[hidden]>
Sent: Thursday, December 14, 2023 9:24 AM
To: Olga Arkhipova via SG15 <sg15_at_[hidden]>
Cc: Olga Arkhipova <olgaark_at_[hidden]>
Subject: Re: [SG15] Proposal for module metadata format to be used by the std library and others

[You don't often get email from koraq_at_xs4all.nl. Learn why this is important at https://aka.ms/LearnAboutSenderIdentification ]

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