> On 13 Dec 2023, at 23:10, Tom Honermann via SG15 <sg15_at_[hidden]> wrote:
>
> 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.

Right, I think that the “base” for each manifest is one ABI-slice (i.e. a mutually-incompatible binary variant).
That can often be on the basis of flags, rather than just the iSA - e.g. soft/hard float.
Those are (for the most part) installed in different places (the current exceptions [that I know of] to that are macOS and AIX which both support multi-slice archives/DSOs) - so we’d need to handle both circumstances.

We end up with multiple BMI favours (interface-incompatible but binary-compatible) flag sets for each ABI slice.

Iain

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