Date: Thu, 14 Dec 2023 23:41:52 +0000
[Bret]
* Apologies. I guess I don't see what the burden on the compiler is.
What do you call “the compiler”?
Sorry, that is not a rhetorical question.
We seem to often believe that all the things we are dealing with here are process-agonistic and we only need that piece of code to be inserted, and often try to tell compiler writers how they should write their compilers with no visibility or appreciation of the processes they follow.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Bret Brown via SG15
Sent: Thursday, December 14, 2023 3:04 PM
To: SG15 <sg15_at_[hidden]>
Cc: Bret Brown <mail_at_[hidden]>
Subject: Re: [SG15] What is the outcome of the 12-12 meeting for the initial question: the location of std module units?
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]<mailto: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]<mailto: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]ocpp.org<mailto:sg15_at_[hidden]>
Cc: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto: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]<mailto:sg15_at_[hidden]>> wrote:
>
> On Thu, Dec 14, 2023, 11:29 Gabriel Dos Reis <gdr_at_[hidden]<mailto: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]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
* Apologies. I guess I don't see what the burden on the compiler is.
What do you call “the compiler”?
Sorry, that is not a rhetorical question.
We seem to often believe that all the things we are dealing with here are process-agonistic and we only need that piece of code to be inserted, and often try to tell compiler writers how they should write their compilers with no visibility or appreciation of the processes they follow.
-- Gaby
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Bret Brown via SG15
Sent: Thursday, December 14, 2023 3:04 PM
To: SG15 <sg15_at_[hidden]>
Cc: Bret Brown <mail_at_[hidden]>
Subject: Re: [SG15] What is the outcome of the 12-12 meeting for the initial question: the location of std module units?
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]<mailto: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]<mailto: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]ocpp.org<mailto:sg15_at_[hidden]>
Cc: René Ferdinand Rivera Morell <grafikrobot_at_[hidden]<mailto: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]<mailto:sg15_at_[hidden]>> wrote:
>
> On Thu, Dec 14, 2023, 11:29 Gabriel Dos Reis <gdr_at_[hidden]<mailto: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]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
_______________________________________________
SG15 mailing list
SG15_at_[hidden]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15
Received on 2023-12-14 23:41:56