C++ Logo

sg15

Advanced search

Re: What is the outcome of the 12-12 meeting for the initial question: the location of std module units?

From: Steve Downey <sdowney_at_[hidden]>
Date: Thu, 14 Dec 2023 10:24:50 -0500
A c++ implementation includes a standard library. I don't think it's
unreasonable to expect `c++ -o hello hello_module.cpp` to work, but if
we're going to insist that everyone build the module interface, then asking
the compiler driver "how" to for the std library it knows about is next
best? Although asking it to just build it seems reasonable to me, too.

On Thu, Dec 14, 2023, 10:20 Bret Brown via SG15 <sg15_at_[hidden]>
wrote:

> I expect that CMake will need to support settings that would appear in
> CMake toolchain files to manually configure all sorts of settings, probably
> including the location of the std module metadata file.
>
> I believe most of the people in this discussion are thinking of how CMake,
> for instance, would be implemented to find a std module metadata file
> absent explicit settings. Right now, CMake works out of the box without a
> CMake toolchain file on all platforms I'm familiar with.
>
> Assuming we agree that metadata files for std modules are necessary,
> viable options CMake can pursue include:
>
> 1) Asking CXX, the C++ compiler, where the file is, similarly to how
> compilers are probed for compiler IDs, versions, standard header search
> paths, etc.
>
> 2) Just hardcoding a lot of assumptions based on combinations of other
> settings like compiler IDs, compiler versions, build environment OS,
> deployed system OS (because of cross compiling), and so on.
>
> 3) Waiting for a de facto or actual standard filesystem layout of some
> sort to be widely enough adopted enough that a modestly sized list of
> specific locations could be examined for std module metadata that will
> match current compilation needs for all targets in the current build.
>
> Are there any other options?
>
> Some mix of the above could be possible, though it would mean once again
> raising the bar for maintaining a cross platform C++ build system. We're
> hoping for a net simpler design for all parties via interop standards for
> this workflow.
>
> Bret
>
> On Thu, Dec 14, 2023, 09:58 Chuanqi Xu via SG15 <sg15_at_[hidden]>
> wrote:
>
>> I don't think there is a **default standard library** for a compiler. For
>> example, for clang, clang will find the libstdc++ on linux but libc++ on
>> macos. It is actually highly platform dependent. The compiler just hardcode
>> these things in the driver.
>>
>> And I feel CMake can do such things better. The ability to run in
>> different platforms is a reason of the success of cmake to me.
>>
>> So the direct answer may be, just to remember it directly with different
>> platforms.
>>
>>
>> Thanks,
>> Chuanqi
>>
>> ------------------------------------------------------------------
>> From:Daniel Ruoso <daniel_at_[hidden]>
>> Send Time:2023 Dec. 14 (Thu.) 22:31
>> To: SG15 <sg15_at_[hidden]>
>> Cc:Michael Spencer <bigcheesegs_at_[hidden]>; Chuanqi <
>> chuanqi.xcq_at_[hidden]>
>> Subject:Re: [SG15] What is the outcome of the 12-12 meeting for the
>> initial question: the location of std module units?
>>
>> On Thu, Dec 14, 2023, 09:24 Chuanqi Xu via SG15 <sg15_at_[hidden]>
>> wrote:
>> 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
>>
>> Let's explore that a bit.
>>
>> Let's say you have a CMake project building against the default system
>> compiler, using that compiler's default standard library.
>>
>> What are the steps CMake would have to take to figure out where the
>> metadata file is?
>>
>> 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
>

Received on 2023-12-14 15:25:00