C++ Logo

sg15

Advanced search

Re: [Tooling] Tooling experience? (was Re: Proposed mission)

From: Boris Kolpackov <boris_at_[hidden]>
Date: Mon, 9 Apr 2018 06:54:21 +0200
Titus Winters <titus_at_[hidden]> writes:

> There's been some general pushback on "macros and preprocessor things make
> various types of tools impossible to deploy." My question is aimed mostly
> at that: do we have evidence of that? Or is it just intuition?

I work on the build2 build system[1]. Dealing with the preprocessor is the
most complex part of building C++ projects.


Titus Winters <titus_at_[hidden]> writes:

> Can you provide concrete examples of the problems you've encountered?

The problem of header dependency extraction combined with auto-generated
headers (e.g., protobufs) is a lethal combination. I think it is quite
telling that most build systems simply do not handle this as part of the
main build phase. They either do not supporting auto-generated code
entirely or have ad-hoc, non-parallelizable pre-build steps for that.

Just to give one concrete example of how deep the rabbit holes go: an
out-of-date auto-generated header might trigger an #error (e.g., a
version check) that would go away if we were to update the header. But
discovering the dependency on the header in the first place requires
a preprocessor run which triggers the #error.

The preprocessor/macros also significantly complicate module dependency
extraction (for Module TS). The set of modules imported by a
translation unit could be affected by the preprocessor (they can
be both #include'ed and #ifdef'ed out). So we have to run the
preprocessor first. And since the header dependency extraction is
essentially also a preprocessor run, it make sense to combine them.
And if the compiler supports partial preprocessing (GCC's
-fdirectives-only and Clang's -frewrite-includes), then it makes
sense to save those for the compilation proper (interestingly,
doing it this way may actually result in faster builds[2]).

And if we add support for macro exporting to modules, it will take
this complexity to the whole new level since now any subsequent
'import' can be affected bu the preceding. Which will require a
constant back-and-forth between the compiler and the build system
while compiling a single translation unit. I am planning to submit
a paper on this with the (working) title "No Sane Build System will
Support Modules with Macros".

So, yeah, the preprocessor is a pain.

[1] https://build2.org
[2] https://build2.org/article/preprocess-compile-performance.xhtml

Boris

Received on 2018-04-09 06:54:36