Hi, all

>> This sounds confusing to me. Currently, the default position of the
standard library is highly related to the platforms. The compiler just
finds it in different method in different platforms. It is somewhat
hardcodings and not elegent.

> Well, if the compiler doesn't do it, the build systems will have to. The
compiler already needs to figure out where the library file is, since it's
driving the linker, so it would not be an excessive additional coupling,
IMHO.

Is there any conclusion now about how to obtain the location information of
metadata file? I'd like to know how to get the build system to find its
location.
Does the build system get it by calling the compiler (e.g. clang
--module-metadata-path), or does it look it up directly from some
standardised hard-coded path?

Currently, the xmake build system has implemented support for msvc std
modules. It directly finds std.ixx and std.compat.ixx from the path of
msvc, and then passes the path to the compiler to generate BMI. e.g.
`Microsoft Visual Studio\\<vs version>\\Preview\\VC\\Tools\\MSVC\\<sdk
version>\\modules\\std.compat.ixx`

But for libstdc++ and libc++, how should the build system find it?

Also, if we don't have the compiler and standard library installed to the
system path, how do we find metadata file? For example, we just compiled
the llvm source code and then directly asked the build system to call
llvm/build/bin/clang to compile std modules.

Ruki

Iain Sandoe via SG15 <sg15_at_[hidden]> 于2023年12月14日周四 07:21写道：

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

-- 
_______________________________________________
Ruki Wang