C++ Logo

sg15

Advanced search

Re: Proposal for module metadata format to be used by the std library and others

From: Tom Honermann <tom_at_[hidden]>
Date: Wed, 13 Dec 2023 18:10:49 -0500
On 12/13/23 2:45 PM, Daniel Ruoso via SG15 wrote:
> On Wed, Dec 13, 2023, 13:45 Tom Honermann <tom_at_[hidden]> wrote:
>
> I think someone mentioned it yesterday, but this will presumably
> have to account for multilib libraries in some way.
>
>
> This is accounted for in the paper that suggested this. The lookup
> will try the ISA code before looking for the naked name.
I don't think a single ISA code suffices as the library variants might
be sliced along various feature sets. But I have little experience in
this area, so I'm not sure. In most cases, predefined macros probably
suffice to build the right BMI.
>
> I think it will be necessary to support paths that are relative to
> some other parameterized location to accommodate dependencies on
> header files or modules provided by other projects/packages.
>
>
> I agree that this is likely going to be necessary eventually, but we
> can probably get away under-specifying for now.
Probably. JSON is pretty extendable but some care is needed to allow
simple things to remain simple. For example, preferring JSON objects
over JSON strings so that additions can be handled by just adding
another key.
>
> Do implementation module units need to be mentioned at all? I'm
> not opposed to allowing for them, but if I'm following correctly,
> since the metadata file is consumed to satisfy module imports,
> they don't contribute to anything that is relevant to import. I
> would expect is-interface to always be true.
>
>
> We still have internal partitions that may be reachable by the
> consumer even if it's not contributing to the external interface.
Sigh, but per Olga, it sounds like scanning might handle this.
>
> Since local-arguments (which I presume to mean compiler command
> line options) are necessarily implementation specific, I think
> this should either be generalized or named such that it reflects
> an implementation dependency.
>
>
> I am actually considering we can under-specify this for now. Unless
> someone can point at a use case where we already need local arguments
> for the std modules

I'm not aware of any immediate necessity.

Tom.

>
> Daniel
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15

Received on 2023-12-13 23:10:52