Date: Fri, 8 Feb 2019 13:14:18 -0500
On 2/8/19 12:58 AM, Mathias Stearn wrote:
>
>
> On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> A couple of people have countered that build system updates are
> required (presumably in excess of just adding '-fmodules' to Clang
> invocations) in order to enable support for Clang Modules. This
> seems trivially incorrect to me, so long as one does not consider
> Clang's module.modulemap files to be part of the build system (I
> don't; they are tool specific configuration files that the build
> system does not need to be aware of).
>
>
> I would hope you are marking the module.modulemap as an input
> dependency of every compilation that uses -fmodules. If you don't then
> you are risking silent miscompilation which is about the worst thing a
> build system can do. And if you are, that means that you have either
> manually added it as an input edge to every compile (unlikely), or you
> modified your build system to teach it to do that automatically*. I
> assume you are primarily referring to deeper structural changes, but
> your implication that you can just add -fmodules to CXXFLAGS and walk
> away seems trivially incorrect to me.
Build systems that rely on the compiler to provide per-TU input
dependencies are likely already covered here. For example, Clang's '-M'
output includes referenced module map files:
$ cat m.cpp
#include <cstdio>
$ clang -c -M -fmodules m.cpp
m.o: m.cpp \
...
/home/tom/products/clang-7.0.0/lib/clang/7.0.0/include/module.modulemap \
...
(I see from other responses that you already discovered this, but I
already wrote the above so I'm sending it anyway).
It does look like build systems that rely on #line scanning for
dependencies will currently miss the dependency as no #line indicators
are emitted for module maps. Perhaps there is a reasonable enhancement
request to be made to Clang here.
You are correct that a missed dependency on a module map file can result
in a miscompilation, but the changes are low (I think the only way that
can happen is if the set of exported sub-modules is changed). Missed
dependencies are bad, but also something that can be improved as QOI in
the build system (I've never yet had the pleasure of working with a
build system that wasn't missing some dependency edges). The point I
was trying to make is that Clang modules don't require build system
updates (other than to pass '-fmodules') to continue to work
more-or-less as well as they already do. On the contrary, the existing
proposal and implementation direction will require major and complicated
build system modifications if more than a handful of modules are to be
used (statically encoding additional compiler invocations can be
reasonable, but doesn't scale).
> *Technically there is an additional option: your build system monitors
> for every file that the compiler opens (eg by LDPRELOAD) and
> automatically adds the modulemap file as an input edge. But I don't
> think you are intending to require every build system to do that.
Certainly not :)
Tom.
>
>
> On Fri, Feb 8, 2019 at 12:33 AM Tom Honermann <tom_at_[hidden]
> <mailto:tom_at_[hidden]>> wrote:
>
> A couple of people have countered that build system updates are
> required (presumably in excess of just adding '-fmodules' to Clang
> invocations) in order to enable support for Clang Modules. This
> seems trivially incorrect to me, so long as one does not consider
> Clang's module.modulemap files to be part of the build system (I
> don't; they are tool specific configuration files that the build
> system does not need to be aware of).
>
>
> I would hope you are marking the module.modulemap as an input
> dependency of every compilation that uses -fmodules. If you don't then
> you are risking silent miscompilation which is about the worst thing a
> build system can do. And if you are, that means that you have either
> manually added it as an input edge to every compile (unlikely), or you
> modified your build system to teach it to do that automatically*. I
> assume you are primarily referring to deeper structural changes, but
> your implication that you can just add -fmodules to CXXFLAGS and walk
> away seems trivially incorrect to me.
Build systems that rely on the compiler to provide per-TU input
dependencies are likely already covered here. For example, Clang's '-M'
output includes referenced module map files:
$ cat m.cpp
#include <cstdio>
$ clang -c -M -fmodules m.cpp
m.o: m.cpp \
...
/home/tom/products/clang-7.0.0/lib/clang/7.0.0/include/module.modulemap \
...
(I see from other responses that you already discovered this, but I
already wrote the above so I'm sending it anyway).
It does look like build systems that rely on #line scanning for
dependencies will currently miss the dependency as no #line indicators
are emitted for module maps. Perhaps there is a reasonable enhancement
request to be made to Clang here.
You are correct that a missed dependency on a module map file can result
in a miscompilation, but the changes are low (I think the only way that
can happen is if the set of exported sub-modules is changed). Missed
dependencies are bad, but also something that can be improved as QOI in
the build system (I've never yet had the pleasure of working with a
build system that wasn't missing some dependency edges). The point I
was trying to make is that Clang modules don't require build system
updates (other than to pass '-fmodules') to continue to work
more-or-less as well as they already do. On the contrary, the existing
proposal and implementation direction will require major and complicated
build system modifications if more than a handful of modules are to be
used (statically encoding additional compiler invocations can be
reasonable, but doesn't scale).
> *Technically there is an additional option: your build system monitors
> for every file that the compiler opens (eg by LDPRELOAD) and
> automatically adds the modulemap file as an input edge. But I don't
> think you are intending to require every build system to do that.
Certainly not :)
Tom.
Received on 2019-02-08 19:14:23