C++ Logo


Advanced search

Re: [Tooling] [isocpp-modules] Round2: Path to modules with old bad build systems

From: Mathias Stearn <redbeard0531+isocpp_at_[hidden]>
Date: Fri, 8 Mar 2019 11:58:20 -0500
On Fri, Mar 8, 2019 at 11:44 AM Tom Honermann <tom_at_[hidden]> wrote:

> Actually, I would expect it to be *easier* for them. Those tools will be
> able to read the files in the zip (or other format) directly without ever
> writing them to disk. There are plenty of libraries for that. If this
> format is accepted as stdin to compilers, those tools should be able to
> synthesize a new stream in memory and then shove it in to the compiler
> without writing a single file to the filesystem until it has found the
> minimal repro to output. What do you expect will make this harder?
> These tools operate on single files today. In the zip case, they would
> now need to mutate not one file, but the collection of files within the zip
> archive.
I think that is unavoidably required for modular source code. You need some
way to keep code in each module unit separate to preserve the correct
semantics. There is no longer a direct equivalent of a preprocessed file
where everything is lumped into a single linear TU. Even if the delineators
were #pragma based, such a tool would need to treat them as if they were
single files. I think a single-stream, multi-file format (whether zip-like
or #pragma-like since they are largely isomorphic) is the closest
equivalent. But its also possible I'm just not creative enough to come up
with something better, so I'm open to better suggestions, as long as they
are semantic preserving.

Received on 2019-03-08 17:58:33