On 2/3/22 9:43 PM, Jon Chesterfield via SG15 wrote:
> 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?

The former would require a common file format; at least for a container
of some kind. That approach is not without merit even if the contained
module artifact(s) remain opaque and compiler or compiler version
specific. For example, a container approach could support "fat" BMIs
that contain module artifacts for multiple compilers or compiler
versions. This would also facilitate some kinds of management via
implementor independent tooling. The downside of this approach is that
it is less accessible than a simple text file.

Gcc has adopted the container approach; its BMI (.nms) files are ELF
containers. They can be inspected with tools like `readelf`.

Tom.

>
> Jon
>
> On Fri, 4 Feb 2022, 01:44 Steve Downey via SG15,
> <sg15_at_[hidden] <mailto:sg15_at_[hidden]>> wrote:
>
>
>
> On Thu, Feb 3, 2022 at 8:07 PM Olga Arkhipova
> <olgaark_at_[hidden] <mailto: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] <mailto:SG15_at_[hidden]>
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
> <https://lists.isocpp.org/mailman/listinfo.cgi/sg15>
>
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15