On 2/4/22 11:39 AM, Gabriel Dos Reis via SG15 wrote:
>
> We also need to account for scenarios where one single container hosts
> several BMIs (for several modules),
>
That seems reasonable.
>
> or where the BMI is embedded either in the .a or the .so (or
> equivalent) to provide self-describing artifacts less disconnected
> (your header units aren’t out-of-sync with the object files anymore).
> I don’t think that does violence to the unixy world.
>
I'm struggling with this one though. Modules are needed at parse time.
Placing them in link-time artifacts seems too late in the tooling
pipeline; a compiler may not know how to extract them from archives or
shared objects. It also complicates the search for module artifacts by
adding more sources; do you search for matching modules by BMIs named on
the command line first, then in linker artifacts? Or perhaps in the
order that they appear on the command line? If so, that has implications
for '-lmylib' vs '-Wl,-lmylib'.

Tom.

> -- Gaby
>
> *From:* SG15 <sg15-bounces_at_[hidden]> *On Behalf Of *Steve
> Downey via SG15
> *Sent:* Thursday, February 3, 2022 5:44 PM
> *To:* Olga Arkhipova <olgaark_at_[hidden]>
> *Cc:* Steve Downey <sdowney_at_[hidden]>; ISO C++ Tooling Study Group
> <sg15_at_[hidden]>
> *Subject:* Re: [SG15] Meeting on February 4th at 9AM Pacific
>
> 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]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15