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