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

[Stephen Kelly]

Sean Silva wrote:

>> 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. 

My goal is to gain experience with clang modules for C++, and possibly to be 
able to communicate the principles behind the design of them, the gotchas, 
the limitations, the requirements and the benefits. I'm learning what I'd 
need to know to write useful blogs of give a useful talk at a conference or 
meetup. 

So, that's why I want to get from 'this file I hacked together does not 
cause explosions' to 'Here are the other things you can put in a modulemap 
file and why you would want to'.

> 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.

Cool, thanks. I'll try this at some point too for sure.

> The "toss them all in a single top-level module" approach causes *all* the
> headers to be included if any of them is included.

Ah! Wow, that's certainly slide-worthy. So 

 #include <QtCore/QString>

 int main(int, char **)
 {
   QString s;
   QObject o;
   QStringListModel m;
   return 0;
 }

compiles with -fmodules but not without it.

That's weird at least.

> 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).

... ie 

 #include <QWidget>

 int main(int, char **)
 {
   QObject o;
   return 0;
 }

compiles without -fmodules and fails with it, until I add export *. 

I'll add that to my qmake patch for generating the modules for now. In that 
patch I can be more-exact though about what to export (qmake knows which 
modules are dependencies). Is there any advantage to doing that? Although I 
can think of a case in the QtSql module I'd have to examine for a breakage 
case (QSqlRelationalDelegate includes QtWidget classes, but qmake may not 
consider that a module-dependency).

>> 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.

It is included by multiple headers. I don't understand the problem though 
you're bringing up though. All TUs are expected to use the same 
qatomic_foo.h.

What is the breakage case you're warning against?

Thanks,

Steve.