<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 26, 2014 at 11:06 AM, Stephen Kelly <span dir="ltr"><<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">Sean Silva wrote:<br>
<br>
> My experience has been that the easiest thing is to start out by just<br>
> doing a "unity module" like<br>
><br>
> module foo {<br>
> header "bar"<br>
> header "baz"<br>
> ...<br>
> }<br>
><br>
> Just list every file in the directory (possibly recursively). Then just<br>
> exclude any headers that are causing problems. That should get you up and<br>
> running pretty fast.<br>
<br>
</span>I did this for Qt5Core and came up with<br>
<br>
 <a href="http://www.steveire.com/Qt5Core.modulemap" target="_blank">http://www.steveire.com/Qt5Core.modulemap</a><br>
<br>
What is the next step?<br></blockquote><div><br></div><div>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 <a href="http://i.imgur.com/8eXR8rG.png">http://i.imgur.com/8eXR8rG.png</a> or <a href="http://i.imgur.com/qNxwZhD.png">http://i.imgur.com/qNxwZhD.png</a> . 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.</div><div><br></div><div>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</div><div><br></div><div>module foo_h {</div><div>  header "foo.h"</div><div>  export *</div><div>}</div><div><br></div><div>(still nested within the top-level module)</div><div><br></div><div>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).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I'd like to understand more about the modulemap language and what should be<br>
specified there. What is the 'export *' stuff for? Qt headers define some<br>
macros such as Q_DECL_CONSTEXPR. Do they need to be explicitly<br>
named/exported in the modulemap file? The macro seems to work fine without<br>
such an export.<br>
<br>
The headers that I exclude from the include/QtCore folder are:<br>
<br>
 qatomic_armv5.h<br>
 qatomic_armv6.h<br>
 qatomic_armv7.h<br>
 qatomic_bootstrap.h<br>
 qatomic_cxx11.h<br>
 qatomic_gcc.h<br>
 qatomic_ia64.h<br>
 qatomic_mips.h<br>
 qatomic_msvc.h<br>
 qatomic_unix.h<br>
 qatomic_x86.h<br>
 qconfig-dist.h<br>
 qconfig.h<br>
 qconfig-large.h<br>
 qconfig-medium.h<br>
 qconfig-minimal.h<br>
 qconfig-nacl.h<br>
 qconfig-small.h<br>
 qobjectdefs_impl.h<br>
 qobject_impl.h<br>
 qsharedpointer_impl.h<br>
 qt_windows.h<br>
<br>
I *could* include qatomic_x86.h to the modulemap, but that header is not<br>
designed for users to include. Users include qatomic.h instead, which<br>
includes the appropriate _foo header.<br></blockquote><div><br></div><div>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.</div><div><br></div><div>-- Sean Silva</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
The _impl headers are also not designed to be included directly, so not<br>
including those in the modulemap also makes sense to me. I suppose the<br>
appropriate version gets compiled into the module binary file included via<br>
the public header.<br>
<br>
I guess on windows, qt_windows.h would need to be included in the modulemap<br>
(assuming windows.h was in another module, probably). So, we would have to<br>
generate the modulemap at the time of building/packaging Qt.<br>
<div class=""><div class="h5"><br>
Thanks,<br>
<br>
Steve.<br>
<br>
<br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br></div></div>