On Wed, Dec 13, 2023, 11:01 Chuanqi Xu <chuanqi.xcq@alibaba-inc.com> 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.

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@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/sg15