Date: Fri, 8 Feb 2019 00:33:00 -0500
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).
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'd like to hear more details from those that believe
build system updates are required to take advantage of Clang modules.
What changes do you believe build systems have required?
I ask this because I am concerned that the design proposed in P1103
(specifically module and import declarations) combined with current
implementation direction (extrinsically managed module artifacts) go
directly against existing practice and, in particular, the two key
features I consider to have been instrumental to the success of the only
widely deployed C++ module system. I believe we should be modeling
standard modules more closely on what has been shown to be deployable at
scale and in practice.
Tom.
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).
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'd like to hear more details from those that believe
build system updates are required to take advantage of Clang modules.
What changes do you believe build systems have required?
I ask this because I am concerned that the design proposed in P1103
(specifically module and import declarations) combined with current
implementation direction (extrinsically managed module artifacts) go
directly against existing practice and, in particular, the two key
features I consider to have been instrumental to the success of the only
widely deployed C++ module system. I believe we should be modeling
standard modules more closely on what has been shown to be deployable at
scale and in practice.
Tom.
Received on 2019-02-08 06:33:04