On 12/14/23 10:20 AM, Bret Brown via SG15 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?

I think that covers it pretty well though I think 1 and 3 are mostly
special cases of 2. Effectively, CMake has to consider the complete tool
chain it is configured to use (either explicitly or implicitly based on
host platform), and how it asks and gets answers for these questions is
necessarily dependent on that tool chain.

There are some scope questions that I think need to be answered. Do we
care about cases like these for the ecosystem IS? (I think we should care)

  * clang++ -target <some-embedded-target> --sysroot /target/system ...
  * g++ -nostdinc++ -isystem /path/to/alt/stdlib ...
  * cl /X /I \path\to\alt\stdlib ...

Note that, for the latter two, the compiler is not informed that the
provided include paths have anything to do with the standard library.

Tom.

>
> 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