Date: Thu, 14 Apr 2022 16:18:19 -0400
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
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
> 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
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
Received on 2022-04-14 20:17:56