Apologies. I guess I don't see what the burden on the compiler is. Why not
have the compiler driver shell out to the "where is the metadata" program
in situations where that's easier than hardcoding or otherwise discovering
this info?

For the record, my preferred design would be to have some standard for
discovering this metadata on a filesystem without probing even a compiler,
which is how CMake finds its modules, pkg-config finds its metadata files,
how any number of dynamic languages find their dependencies, etc. I haven't
been insisting on that because I expected it would be too much to define
that protocol fast enough to unblock the implementation of 'import std;'.
Compiler probing seems like a good enough solution in the meantime. I'm
less sure of introduction of new workflows that involve new tools that
don't exist yet.

And, to an earlier point by Gaby, any time we add accidental complexity to
these workflows by settling for implementation defined interop, we are
adding to the "N+1 standards" problem... except without the standard. If
hardcoding more and more assumptions into CMake is the acceptable result of
our deliberation, we make portable build system interop more and more
undefined and particular. We might as well declare CMake the reference
implementation of a build system standard if that's the plan.

Bret

On Thu, Dec 14, 2023, 14:24 Gabriel Dos Reis via SG15 <sg15_at_[hidden]>
wrote:

> [Rene]
> > There could be an agreed upon
> > configuration interrogation program that can serve the same purpose.
>
> I suspect that is a better path than insisting "the compiler knows".
>
> -- Gaby
>
> -----Original Message-----
> From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of René Ferdinand
> Rivera Morell via SG15
> Sent: Thursday, December 14, 2023 10:08 AM
> To: sg15_at_[hidden]
> Cc: René Ferdinand Rivera Morell <grafikrobot_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 at 11:05 AM Daniel Ruoso via SG15
> <sg15_at_[hidden]> wrote:
> >
> > On Thu, Dec 14, 2023, 11:29 Gabriel Dos Reis <gdr_at_[hidden]> wrote:
> >>
> >> CL.exe for instance has no fogging clue, but the packager knows. In
> the prior experimental std.* modules, CL.exe has to be told where those
> BMIs are.
> >>
> >> The higher level point is: insisting that only the compiler knows is
> just wrong.
> >
> >
> > In that case it seems that we don't have enough foundations to build a
> standardized solution to this problem.
> >
> > The outcome is that build systems will have to cope with that divergence.
> >
> > That being said, in the case of Linux (and I presume MacOS as well), the
> compiler is the one best positioned to answer that question (since it is
> already deeply integrated with the standard libraries it supports).
> >
> > Which means on those platforms the build systems will be able to have a
> single converging solution.
>
> It is possible for the toolset installer, the VS installer in the
> Windows case, to install a file that the compiler can dynamically use
> to report the information. It would be up to the people creating the
> packager and the people creating the compiler to coordinate on such a
> method. Hence it does seem possible to me to implement the single
> convergence point of using the compiler driver for this in the msvc
> situation. As an alternative.. There could be an agreed upon
> configuration interrogation program that can serve the same purpose.
> Similar to how on Windows there's a globally available vswhere.exe
> program that can report the various install locations of the VS
> components (including msvc). Some build systems already use vswhere to
> locate msvc (b2 for example). Hence it is known to work. A similar
> approach could work for other platforms.
>
> --
> -- René Ferdinand Rivera Morell
> -- Don't Assume Anything -- No Supone Nada
> -- Robot Dreams - http://robot-dreams.net/
> _______________________________________________
> 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
>