C++ Logo


Advanced search

Re: [Tooling] Clang Modules and build system requirements

From: Mathias Stearn <redbeard0531_at_[hidden]>
Date: Fri, 8 Feb 2019 12:26:41 -0500
On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_[hidden]> wrote:

> I've been recently claiming two properties of Clang Modules that I believe
> have been central to their success.
> 1. Clang modules are built on #include directives in such a way that
> existing tools that have no knowledge of Clang modules continue to work as
> they always have.
> 2. Modules are built implicitly on demand (by default) such that build
> system updates are not required (other than to pass '-fmodules' to enable
> the feature).
Unfortunately that design of "compiler handles everything, build systems
are oblivious" means that clang modules break several important
build-system-adjacent tools, such as ccache[1] and icecream[2]. distcc is
likely also affected since it originally worked the same as icecream. It is
possible that the new "pump" mode makes it work in distcc, but I don't have
a cluster to test that on.

I think the clang modules design makes it somewhere between hard and
impossible for these kinds of tools to work well with them. Support for
distributed builds is one of my major concerns with modules. Almost any
form of modules that isn't just "better scoping in headers with no caching"
will make distributed builds more complicated than today. I want to hope
that this problem is solvable though. Having the machinery hidden in the
compiler rather than explicitly managed makes it substantially harder
(while admittedly making simple builds simpler).

[2] This is how I tested. It also fails with remote cpp enabled. If there
is a better way, I'd be happy to try it.
/usr/lib/icecream/bin/icecc clang++ -fmodules -c test.cpp
test.cpp:1:29: fatal error: module 'Header' not found
#pragma clang module import Header /* clang -E: implicit import for
#include "header.h" */

Received on 2019-02-08 18:26:54