[cfe-dev] How do I try out C++ modules with clang?

[Sean Silva]

On Sun, Oct 26, 2014 at 11:06 AM, Stephen Kelly <steveire at gmail.com> wrote:

> Sean Silva wrote:
>
> > My experience has been that the easiest thing is to start out by just
> > doing a "unity module" like
> >
> > module foo {
> > header "bar"
> > header "baz"
> > ...
> > }
> >
> > Just list every file in the directory (possibly recursively). Then just
> > exclude any headers that are causing problems. That should get you up and
> > running pretty fast.
>
> I did this for Qt5Core and came up with
>
>  http://www.steveire.com/Qt5Core.modulemap
>
> What is the next step?
>

It depends on what your goals are. Once I got an initial module map
working, the first thing I did was to analyze build time. If you are on
Mac, then the attached patch to clang and the attached DTrace script could
prove useful. Using the instrumented clang as your compiler, the DTrace
script will print out how much total time Clang spends parsing each file,
summed across the entire build (you will probably want to redirect its
output to a file since it will be printing something for every file in the
build; it also has some PHONY_* targets that account for time not spent
parsing). With a small amount of post-processing, you can generate pie
charts like http://i.imgur.com/8eXR8rG.png or http://i.imgur.com/qNxwZhD.png
. If you aren't familiar with Dtrace or need help post-processing the
output feel free to let me know and I can help. The script can also be
tweaked to collect interesting information like the total number of times
each file is included.

The "toss them all in a single top-level module" approach causes *all* the
headers to be included if any of them is included. If this is problematic
for your use case, then the next step might be to replace every `header
"foo.h"` with

module foo_h {
  header "foo.h"
  export *
}

(still nested within the top-level module)

The `export *` just means "export declarations from any modules I depend
on", which is what you almost always want at the moment since that matches
textual inclusion semantics. I.e. if someone was including "QSubclass" and
relying on that include to bring in "QBaseclass" (or a system header or
whatever).


>
> I'd like to understand more about the modulemap language and what should be
> specified there. What is the 'export *' stuff for? Qt headers define some
> macros such as Q_DECL_CONSTEXPR. Do they need to be explicitly
> named/exported in the modulemap file? The macro seems to work fine without
> such an export.
>
> The headers that I exclude from the include/QtCore folder are:
>
>  qatomic_armv5.h
>  qatomic_armv6.h
>  qatomic_armv7.h
>  qatomic_bootstrap.h
>  qatomic_cxx11.h
>  qatomic_gcc.h
>  qatomic_ia64.h
>  qatomic_mips.h
>  qatomic_msvc.h
>  qatomic_unix.h
>  qatomic_x86.h
>  qconfig-dist.h
>  qconfig.h
>  qconfig-large.h
>  qconfig-medium.h
>  qconfig-minimal.h
>  qconfig-nacl.h
>  qconfig-small.h
>  qobjectdefs_impl.h
>  qobject_impl.h
>  qsharedpointer_impl.h
>  qt_windows.h
>
> I *could* include qatomic_x86.h to the modulemap, but that header is not
> designed for users to include. Users include qatomic.h instead, which
> includes the appropriate _foo header.
>

This will break if multiple headers in the module map end up including
qatomic.h (whichever one comes first will include the declarations of
qatomic.h). If qatomic.h is only included from a single header in the
module map you should be fine though.

-- Sean Silva



>
> The _impl headers are also not designed to be included directly, so not
> including those in the modulemap also makes sense to me. I suppose the
> appropriate version gets compiled into the module binary file included via
> the public header.
>
> I guess on windows, qt_windows.h would need to be included in the modulemap
> (assuming windows.h was in another module, probably). So, we would have to
> generate the modulemap at the time of building/packaging Qt.
>
> Thanks,
>
> Steve.
>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141027/3c2cffeb/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dtraceprobes.patch
Type: application/octet-stream
Size: 6733 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141027/3c2cffeb/attachment.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trace_enter_exit.d
Type: application/octet-stream
Size: 1802 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20141027/3c2cffeb/attachment-0001.obj>