I expect that the interesting list of dependencies in these metadata files
is the list of *library* dependencies. That information is not discoverable
with the module scanning process. And those names would be used to discover
subsequent module metadata files identifiable by the dependency names.

And it's useful to know if a standard library depends on other libraries
(and their hypothetical C++ modules!) when the build system configures how
to parse the std module. For instance, current implementations of libstdc++
depend on non-standard libraries to implement std::thread. Of course we're
sort of encroaching on library metadata at this point. Maybe we can
convince ourselves that we this a tolerable limitation in the current
design to be addressed later.

I like the idea of the module metadata files including module to module
dependencies as well, though it's less important to know that info because
we need to support scanning anyway, at least for now. But having that info
to detect mistakes and potentially even short circuit scanning would be
interesting. For future work.

Bret


On Thu, Dec 14, 2023, 15:07 Olga Arkhipova via SG15 <sg15_at_[hidden]>
wrote:

> >>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
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>