On Wed, Dec 13, 2023 at 07:17:16 +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.

Given this context from the original email:

 * Module discovery should be subordinate to ABI decisions having been made
already. The outcome is that we don't expect the module metadata to be used
to discover which ABI settings are available for a given standard library
or how to choose between them. The way that this manifests is that,
following the lead from P2577R2, we expect the libraries to ship those
metadata files on a one-to-one mapping with the library binary used as
input to the linker.

the "module metadata" will be found based on the library in use, so it
seems redundant to me. Or are there tools that want to discover modules
without reference to the library in use that…still care about library in
some way? It seems to be backwards because one cannot just divine object
code availability like that; you have to work with confines the ABI
decisions made in the SDK offering (if you care about the library).
Static analysis may want to "play pretend" to analyze alternative ABIs,
but they don't care about the library AFAIK.

> {
> "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.
> }

Standard libraries may have library dependencies (e.g., `libstdc++` may
use `libc` or `libatomic` to implement its APIs). If the answer is "but
they won't have modules", are we saying that this is only relevant for
module-providing referenced libraries? Then it seems quite inadequate
for packaging. I'd say let's leave CPS to tackle package descriptions
and this to handle what-modules-do-we-have-to-consider once we've
determined what libraries to use (via CPS, innate knowledge of
platforms, .pc files, user-specified dependencies, etc.).

--Ben