Hi,
 thanks for the information. I don't there will be a post about notes.
> GCC compatible compiler drivers already have `-print-file-name` that can be used for this purpose
 I don't think the compiler is responsible to find the metadata file. And `-print-file-name` is just an interface that won't reduce the amount of work to support that.
Following off are the comments from Tom in another thread:
>> On Wed, Dec 13, 2023, 11:01 Chuanqi Xu <chuanqi.xcq_at_[hidden] <mailto:chuanqi.xcq_at_[hidden] >> wrote:
>> 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.
I believe there are implementations, specifically some embedded toolchains, where the compiler driver isn't used to drive the linker. I don't think we should assume such coupling.
>> And currently when we (the users) want to use a different standard library or different version of the same library, we (the users) will tell the location of the standard library to the build systems and it would be the job of the build systems to tell this to the compiler.
> Right, but that's still at a much higher level (such as the directory where the "gcc toolchain" is).
> The build system currently doesn't have to understand anything about the standard library beyond what argument to give to the compiler.
> And, more importantly, in the default case the build system doesn't even know what the standard library is, it just relies on the compiler to do something sensible.
> For those reasons I think the compiler is in the best position to answer that question.
For gcc and clang, yes, but not in general. Many compilers (including Microsoft's I believe) are not particularly aware of the standard library and rely on environment variables or other configuration files to communicate additional include and linker paths. Those paths are not necessarily limited to the standard library. Those compilers could, of course, demand that such external configuration be extended to communicate additional details, but again, we should not assume that compilers in general have the awareness that the gcc and clang drivers (necessarily) do.
And Gaby has a +1 for this:
> Let’s keep the “unix philosophy”: each tool does one thing, and one thing only; and well. Then use composition to build up.
Thanks,
Chuanqi
------------------------------------------------------------------
From:Michael Spencer <bigcheesegs_at_gmail.com>
Send Time:2023 Dec. 14 (Thu.) 17:51
To: SG15 <sg15_at_[hidden]>
Cc:Chuanqi <chuanqi.xcq_at_alibaba-inc.com>
Subject:Re: [SG15] What is the outcome of the 12-12 meeting for the initial question: the location of std module units?
On Wed, Dec 13, 2023 at 8:23 AM Chuanqi Xu via SG15 <sg15_at_[hidden] <mailto:sg15_at_[hidden] >> wrote:
Hi Guys,
 I didn't take part in the meeting so I am curious. After the meeting, I see plenty of discussions about module metadata files. I am not against this.
But I am wondering if the initial question got answered. I didn't see it anywhere. Sorry if I missed.
 In my mind, the motivation of the meeting should be the location of the std modules. Should it be <PREFIX>/modules/c++/v1? Should it be `/usr/include/c++/$version`? Or should it be `$PREFIX/share/c++/modules`? ....
 Do we have any consensus on this?
Thanks,
Chuanqi
To expand on Daniel's answer a bit more (still waiting on the meeting notes to get posted).
We agreed that:
* We need a metadata file because there are additional flags needed and how you compile it depends on the library binary you're linking against
* The compiler needs to say where that file is given a base command line (so including target and ABI affecting flags)
 * GCC compatible compiler drivers already have `-print-file-name` that can be used for this purpose
 * Ecosystem IS should document this
Also discussed that GCC and LLVM can talk to each other to coordinate on filesystem layout, but isn't 100% required because of the metadata file
- Michael Spencer