What's the point of embedding information in a second file next to the
first one, when it could be written directly into the first one?

Jon

On Fri, 4 Feb 2022, 01:44 Steve Downey via SG15, <sg15_at_[hidden]>
wrote:

>
>
> On Thu, Feb 3, 2022 at 8:07 PM Olga Arkhipova <olgaark_at_[hidden]>
> wrote:
>
>> The compiler will have to find all BMIs so their locations should be
>> defined by some command line options.
>>
>> My point is that the same options can be used to find the .d.json files.
>>
>>
>>
>> Thanks,
>>
>> Olga
>>
>> I agree that if the build system can figure out how to do one, it can do
> the other, as long as there is some discernible relationship between the
> bmi and the .d.json file. But in a typical unixy environment, libraries and
> other artifacts to be consumed are not separated out. Perhaps, though the
> bmi and .d.json both live together in an isolated filesystem-like thing
> based on the module name? E.g. a directory or zip file, or some such. On
> the other hand, since .d.json is intended to be portable, I would expect to
> find it in something like /usr/share/module_${name} in an FHS style system?
> Or if a library provides multiple modules, underneath
> /usr/share/lib${name}/?
> Replace /usr with /usr/local/, ~, ${etcetera}, etc above.
>
> (sorry I sent this only to Olga, now replying on list, Olga if you reply,
> either here or add the list back?)
>
>> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>