Date: Fri, 15 Apr 2022 07:50:32 -0400
On 4/14/22 16:18, Ben Boeckel via Ext wrote:
> On Thu, Apr 14, 2022 at 15:09:35 +0200, Boris Kolpackov wrote:
>> Ben Boeckel via Ext <ext_at_[hidden]> writes:
>>> Need? No. Even with different suffixes, a scanner is still necessary to
>>> know what order files need to be compiled in.
>>
>> A (pre-)scanner is not the only way to do it. Another approach is a
>> module mapper (implemented in GCC, being implemented in Clang, used
>> in build2).
>
> Well, an active module mapper. CMake just creates the static files which
> handle the GCC's module mapper protocol.
>
>> With the mapper approach you don't need to pre-scan everything but
>> you do need to map module names to module interface files. Having
>> a separate extension for interface files helps narrow down the
>> candidate pool.
>
> While true, I have doubts about the scalability of holding umpteen
> compiler instances around while executing more to find the bottleneck
> TU. Unsatisifiable requests also end up taking way more resources
> without smarter caching mechanisms to store that information across
True, but IIUC that is how clang's implicit module machinery already
works. using the module map, the compiler will fork to compile an
implicit module (equivalent of a header unit). I don't know how
concurrency concerns are addressed. (I don't have data on how this
scheme behaves in practice)
> attempts. Which is fine if you're implementing your own build executor I
> suppose. Getting Make or Ninja to understand it without complicated
> stamp juggling doesn't sound fun though.
>
> --Ben
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2022/04/19012.php
>
> On Thu, Apr 14, 2022 at 15:09:35 +0200, Boris Kolpackov wrote:
>> Ben Boeckel via Ext <ext_at_[hidden]> writes:
>>> Need? No. Even with different suffixes, a scanner is still necessary to
>>> know what order files need to be compiled in.
>>
>> A (pre-)scanner is not the only way to do it. Another approach is a
>> module mapper (implemented in GCC, being implemented in Clang, used
>> in build2).
>
> Well, an active module mapper. CMake just creates the static files which
> handle the GCC's module mapper protocol.
>
>> With the mapper approach you don't need to pre-scan everything but
>> you do need to map module names to module interface files. Having
>> a separate extension for interface files helps narrow down the
>> candidate pool.
>
> While true, I have doubts about the scalability of holding umpteen
> compiler instances around while executing more to find the bottleneck
> TU. Unsatisifiable requests also end up taking way more resources
> without smarter caching mechanisms to store that information across
True, but IIUC that is how clang's implicit module machinery already
works. using the module map, the compiler will fork to compile an
implicit module (equivalent of a header unit). I don't know how
concurrency concerns are addressed. (I don't have data on how this
scheme behaves in practice)
> attempts. Which is fine if you're implementing your own build executor I
> suppose. Getting Make or Ninja to understand it without complicated
> stamp juggling doesn't sound fun though.
>
> --Ben
> _______________________________________________
> Ext mailing list
> Ext_at_[hidden]
> Subscription: https://lists.isocpp.org/mailman/listinfo.cgi/ext
> Link to this post: http://lists.isocpp.org/ext/2022/04/19012.php
>
-- Nathan Sidwell
Received on 2022-04-15 11:50:36