From: Boris Kolpackov <boris@codesynthesis.com>
To: Ben Boeckel <ben.boeckel@kitware.com>
Cc: gcc@gcc.gnu.org
Subject: Re: [modules] Preprocessing requires compiled header unit modules
Date: Mon, 25 Apr 2022 11:42:14 +0200 [thread overview]
Message-ID: <boris.20220425112037@codesynthesis.com> (raw)
In-Reply-To: <YmLSVTh2Uax7bfQR@farprobe>
Ben Boeckel <ben.boeckel@kitware.com> writes:
> If we need to know and have dependencies prepared before we can figure
> out the dependencies for a TU, modules are unsolvable (without an active
> build executor). If C++ implementations are really going to require
> that, then [...] the following tools are all unsuitable for C++ with
> header units without major overhauls (alphabetical):
>
> - autoconf/automake
> - cmake
> - gn
> - gyp
> - make (not GNU make, though even that requires some active
> involvement via the socket communications)
> - meson
> - ninja
A couple of points:
1. Firstly, this only applies to header units, not named modules.
2. I am not sure what you mean by "active build executor" (but it
does sound ominous, I will grant you that ;-)).
3. I agree some build systems may require "major overhauls" to
support header units via the module mapper. I would like this
not to be the case, but so far nobody has implemented an
alternative (that I am aware of) that is correct and scalable
and I personally have doubts such a thing is achievable.
> > Even if we manage to do this, there are some implications I
> > am not sure we will like: the isolated macros will contain
> > inclusion guards, which means we will keep re-scanning the
> > same files potentially many many time. Here is an example,
> > assume each header-unitN.hpp includes or imports <functional>:
>
> Note that scanning each module TU only happens once. Header units might
> just get *read* in the course of scanning other units.
>
> And headers are read multiple times already over the lifetime of the
> build, so we're not making things worse here.
I am not sure I follow. Say we have 10 TUs each include or import
10 headers each of which includes <functional>. If we use include,
then when scanning each of these 10 TUs we have to scan <functional>
once (since all the subsequent includes are suppressed by include
guards). So total of 10x1=10 scans of <functional> for the entire
build.
Now if instead of include we use import (which, during the scan, is
treated as include with macro isolation), we are looking at 10 scans
of <functional> for each TU (because the include guards are ignored).
So total of 10x10=100 scans of <functional> for the build.
What am I missing?
next prev parent reply other threads:[~2022-04-25 9:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-24 23:46 Ben Boeckel
2022-04-21 4:05 ` Boris Kolpackov
2022-04-21 12:05 ` Ben Boeckel
2022-04-21 17:59 ` Iain Sandoe
2022-04-21 18:08 ` Ben Boeckel
2022-04-21 18:18 ` Iain Sandoe
2022-04-22 14:08 ` Boris Kolpackov
2022-04-22 15:06 ` Iain Sandoe
2022-04-25 9:20 ` Boris Kolpackov
2022-04-22 16:05 ` Ben Boeckel
2022-04-25 9:42 ` Boris Kolpackov [this message]
2022-04-25 11:34 ` Ben Boeckel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=boris.20220425112037@codesynthesis.com \
--to=boris@codesynthesis.com \
--cc=ben.boeckel@kitware.com \
--cc=gcc@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).