Date: Wed, 13 Dec 2023 19:36:15 +0000
[Tom]
* [...] the compiler driver isn't used to drive the linker. I don't think we should assume such coupling.
+1.
Let's keep the "unix philosophy": each tool does one thing, and one thing only; and well. Then use composition to build up.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
Sent: Wednesday, December 13, 2023 8:52 AM
To: sg15_at_[hidden]; Chuanqi Xu <chuanqi.xcq_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] Proposal for module metadata format to be used by the std library and others
On 12/13/23 11:14 AM, Daniel Ruoso via SG15 wrote:
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.
Tom.
Daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
* [...] the compiler driver isn't used to drive the linker. I don't think we should assume such coupling.
+1.
Let's keep the "unix philosophy": each tool does one thing, and one thing only; and well. Then use composition to build up.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Tom Honermann via SG15
Sent: Wednesday, December 13, 2023 8:52 AM
To: sg15_at_[hidden]; Chuanqi Xu <chuanqi.xcq_at_[hidden]>
Cc: Tom Honermann <tom_at_[hidden]>
Subject: Re: [SG15] Proposal for module metadata format to be used by the std library and others
On 12/13/23 11:14 AM, Daniel Ruoso via SG15 wrote:
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.
Tom.
Daniel
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
Received on 2023-12-13 19:36:19