[cmake-developers] Experiments in CMake support for Clang (header & standard) modules

[Stephen Kelly]

David Blaikie wrote:

>> Nope, scratch that ^ I had thought that was the case, but talking more
>> with Richard Smith it seems there's an expectation that modules will be
>> somewhere between header and library granularity (obviously some small
>> libraries today have one or only a few headers, some (like Qt) have many
>> - maybe those on the Qt end might have slightly fewer modules than the
>> have headers - but still several modules to one library most likely, by
>> the sounds of it)
>>
>>
>> Why? Richard maybe you can answer that? These are the kinds of things I
>> was trying to get answers to in the previous post to iso sg2 in the
>> google group. I didn't get an answer as definitive as this, so maybe you
>> can share the reason behind such a definitive answer?
>>
> 
> It's more that the functionality will allow this & just judging by how
> people do things today (existing header granularity partly motivated by
> the cost of headers that doesn't apply to modules), how they're likely to
> do things in the future (I personally would guess people will probably try
> to just port their headers to modules - and a few places where there are
> circular dependencies in headers or the like they might glob them up into
> one module).


It seems quite common to have one PCH file per shared library (that's what 
Qt does for example). What makes you so sure that won't be the case with 
modules?

I'd say that what people will do will be determined by whatever their tools 
optimize for. If it is necessary to list all used modules on the compile 
line, people would choose fewer modules. If 'import QtCore' is fast and 
allows the use of QString and QVariant etc and there is no downside, then 
that will be the granularity offered by Qt (instead of 'QtCore.QString'). 
That is also comparable to '#include <QtCore>' which is possible today.

>> I just looked through the commits from Boris, and it seems he made some
>> changes relating to -fmodule-file=. That still presupposes that all
>> (transitively) used module files are specified on the command line.
>>
> 
> Actually I believe the need is only the immediate dependencies - at least
> with Clang's implementation.

Ok. That's not much better though. It still means editing/generating the 
buildsystem each time you add an import. I don't think a model with that 
requirement will gain adoption.

>> I was talking about the -fprebuilt-module-path option added by Manman Ren
>> in https://reviews.llvm.org/D23125 because that actually relieves the
>> user/buildsystem of maintaining a list of all used modules (I hope).
>>
> 
> *nod* & as you say, GCC has something similar. Though the build system
> probably wants to know about the used modules to do dependency analysis &
> rebuilding correctly. 

Yes, presumably that will work with -MM.

> Yeah, thanks for the link - useful to read.

There seems to be a slew of activity around modules at the moment. You can 
read some other reactions here which might have input for your paper:

https://www.reddit.com/r/cpp/comments/8jb0nt/what_modules_can_actually_provide_and_what_not/

https://www.reddit.com/r/cpp/comments/8j1edf/really_think_that_the_macro_story_in_modules_is/

I look forward to reading your paper anyway.

>> I think clang outputs the definitions in a separate object file, but GCC
>> currently doesn't. Perhaps that's a difference that cmake has to account
>> for or pass on to the user.
>>
> 
> Clang outputs frontend-usable (not object code, but serialized AST usable
> for compiling other source code) descriptions of the entire module
> (whatever it contains - declarations, definitions, etc) to the .pcm file.
> It can then, in a separate step, build an object file from the pcm. I
> think GCC produces both of these artifacts in one go - but not in the same
> file.

Ok, I must have misremembered something.


>> Sure. I didn't notice anything from reading, but I also didn't try it
>> out. You might need to provide a repo with the module.modulemap/c++ files
>> etc that are part of your experiment. Or better, provide something based
>> on modules-ts that I can try out.
>>
> 
> *nod* I'll see if I can get enough of modules-ts type things working to
> provide some examples, but there's some more variance/uncertainty there in
> the compiler support, etc.

Something working only with clang for example would be a good start.

>> I'm guessing that's enough for you to implement what you want as an
>> experiment?
>>
> 
> OK, so in that case it requires source changes to cmake? *nod* sounds
> plausible - I appreciate the pointers. I take it that implies there's not
> a way I could hook into those file kinds and filters without changing
> cmake? (ie: from within my project's cmake build files, without modifying
> a cmake release)

There is no way to hook into the system I described without patching CMake. 
Your custom command approach might be the way to do that if it is the 
priority.

Thanks,

Stephen.