On 4/25/22 12:54 PM, Iain Sandoe wrote:
>
>> On 25 Apr 2022, at 17:37, Tom Honermann <tom_at_[hidden]> wrote:
>>
>> On 4/25/22 12:22 PM, Iain Sandoe wrote:
>>>> On 25 Apr 2022, at 17:15, Tom Honermann <tom_at_[hidden]> wrote:
>>>>
>>>> On 4/25/22 9:40 AM, Iain Sandoe wrote:
>>>>>> On 25 Apr 2022, at 14:36, Peter Dimov via SG15 <sg15_at_[hidden]> wrote:
>>>>>>
>>>>>> Daniel Ruoso wrote:
>>>>>>> Em seg., 25 de abr. de 2022 às 09:06, Peter Dimov <pdimov_at_[hidden]>
>>>>>>> escreveu:
>>>>>>>> All that's also true without modules, but we still make it possible for
>>>>>>>> c++ hello.cc
>>>>>>>> to produce a working hello world executable
>>>>>>> FWIW, I'd be on board with a proposal for a "trivial build system"
>>>>>>> interface to be supported in various toolchains with the same command line
>>>>>>> and options. Maybe we can even convince our toolchain vendors to include
>>>>>>> such a tool. I think focusing on the compiler executable specifically as the one
>>>>>>> having to implement that is a mistake.
>>>>>> That's also something we already have, because c++ in the above is
>>>>>> typically the "compiler driver" executable, which invokes the compiler front
>>>>>> end, the compiler back end, [the assembler], and the linker.
>>>>> Agreed, but the driver typically makes decisions about forming commands
>>>>> based on flags provided and suffixes to files.
>>>>>
>>>>> (at least for the two I am familiar with) it does not do dependency analysis
>>>>> nor does it have any need to parse the source.
>>>> Dependency analysis need not be required for use of a modular standard library.
>>>>
>>>> I don't think anyone is asking for the driver to support arbitrary modules. The request is that it be able to handle the standard library.
>>> My comment was in response to the “we already have a trivial build system in the driver”;
>>> I was not intending to be philosophical (I completely agree that to the end user it makes no difference where the functionality resides - just how it looks)
>>>
>>> However, for the drivers with which I am familiar, they are doing a very complex job of managing the interactions between all the various flags, source code dasignations and all the other stuff that the standard does not describe.
>> I agree, they are surprisingly complex.
>>> That job is quite orthogonal to the one of deciding how to find a BMI for <vector> … especially, since to date the driver would never parse any source code to see that it even needed to consider vector.
>> I disagree, at least somewhat. Consider an invocation like 'clang++ t.cpp -o t'. The driver will search for, and attempt to link with, the standard C++ library (-lstdc++ or -lc++) regardless of whether the program being compiled requires is.
> Which works for arbitrary command line options because of ABI boundary guarantees.
>
> NOTE: I am not arguing against the principle of what you’re asking for - as it happens I agree with it - I am just trying to set expectations…
>
> With modules (at least for clang and GCC) there is no such ABI isolation from the other options on the command line. For those implementations modules are not some kind of “c++ byte code” but rather tied to the compilation environment - so that it is not practicable to have pre-built modules covering every circumstance. ( as an aside I recall we briefly discussed c++ byte code in SG7, but the conversation did not get far ).
>
> So, one has to expect that (albeit hopefully hidden from the user) the build of <vector> might have to happen for the set of command line flags in force for "this compilation".
>
> Unless one needs the resulting BMI more than once, it might not buy a whole lot c.f. just including <vector> .. (speculation of course, and we might figure out some caching system that would work for a typical project flow .. ).

100% agreed. Thanks, Iain.

Tom.

>
> Iain
>
>
>>> So, please read my comment as an engineering “what we have now is far from what we would need, it’s not a done deal”.
>> Thank you, that is appreciated :)
>>>>> I suspect it would be better to place the ‘trivial build’ system as a separate
>>>>> entity (perhaps invoked by the driver) rather than upgunning the driver to
>>>>> have those properties.
>>> Nathan’s mapper-server along with the module-mapper interface can be seen as such a facility.
>> Indeed, and I think is worth considering the possibility of the mapper-server running within the driver (limited to support of the standard library) unless a mapper-server is explicitly specified on the driver command line.
>>
>> Tom.
>>
>>> Iain
>>>