<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Mon, Apr 30, 2018 at 3:30 PM Stephen Kelly <<a href="mailto:steveire@gmail.com" target="_blank">steveire@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<div class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-cite-prefix">On 04/20/2018 01:39 AM, David Blaikie
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi there,<br>
<br>
I'm experimenting with creating examples (& potential
changes to CMake itself, if needed/useful) of building clang
modules (currently using the semi-backwards compatible "header
modules", with the intent of also/moving towards supporting
pre-standard C++ modules in development in Clang).<br>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Great! Thanks for reaching out. Sorry it has taken me a while to
respond. </div></blockquote></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>No worries - thanks for getting back to me!<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Have you had other response off-list?</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><br>Nah - chatted a little with coworkers (fellow Clang/LLVM developers - mostly Richard Smith & Chandler Carruth) off-list, but nothing much more.<br></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">The basic commands required are:<br>
<br>
clang++ -fmodules -xc++ -Xclang -emit-module -Xclang
-fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm<br>
clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp<br>
clang++ -c foo.pcm<br>
clang++ foo.o use.o -o a.out<br>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Ok. Fundamentally, I am suspicious of having to have a
-fmodule-file=foo.pcm for every 'import foo' in each cpp file. I
shouldn't have to manually add that each time I add a new import to
my cpp file. Even if it can be automated (eg by CMake), I shouldn't
have to have my buildsystem be regenerated each time I add an import
to my cpp file either.<br>
<br>
That's something I mentioned in the google groups post I made which
you linked to. How will that work when using Qt or any other
library?<br></div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>- My understanding/feeling is that this would be similar to how a user has to change their link command when they pick up a new dependency.<br><br>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)<br><br><br>Now, admittedly, external dependencies are a little more complicated than internal (within a single project consisting of multiple libraries) - which is why I'd like to focus a bit on the simpler internal case first.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Today, a beginner can find a random C++ book, type in a code example
from chapter one and put `g++ -I/opt/book_examples prog1.cpp` into a
terminal and get something compiling and running. With modules,
they'll potentially have to pass a whole list of module files too.<br></div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Yeah, there's some talk of supporting a mode that doesn't explicitly build/use modules in the filesystem, but only in memory for the purpose of preserving the isolation semantics of modules. This would be used in simple direct-compilation cases like this. Such a library might need a configuration file or similar the compiler can parse to discover the parameters (warning flags, define flags, whatever else) needed to build the BMI.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Lots of people manually maintain Makefile-based buildsystems today,
and most other companies I've been inside of have their own custom
tool or bunch of python scripts, or both. Manually changing such
buildsystems to add -fmodule-file or -fmodule-map-file each time an
import is added is a significant barrier.<br>
<br>
Will my project have to compile the modules files for all of my
dependencies?</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Yes - and that's where the external dependencies get complicated.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> Even more complication for my buildsystem. Do I have
to wait for my dependencies to modularize bottom-up before I can
benefit from modules?</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>There are some ideas about how to handle that ('legacy headers'/modules in Richard's work/proposed amendment to the TS), but I'm trying to focus on a few of the simpler cases first.<br> </div></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> If my dependency does add 'module foo' to
their header files, or whatever the current syntax is, can I
continue to #include <foo> or is that a source incompatible
change?</div></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>I believe it'd be a source incompatible change. You could continue to provide a header for your module separately. They'd likely have different extensions anyway.</div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">I raised some of these issues a few years ago regarding the clang
implementation with files named exactly module.modulemap:<br>
<br>
<a class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-txt-link-freetext" href="http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html" target="_blank">http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html</a><br>
<br>
<a class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-txt-link-freetext" href="http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html" target="_blank">http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html</a><br>
<br>
Interestingly, GCC is taking a directory-centric approach in the
driver (-fmodule-path=<dir>) as opposed to the 'add a file to
your compile line for each import' that Clang and MSVC are taking:<br>
<br>
<a class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-txt-link-freetext" href="http://gcc.gnu.org/wiki/cxx-modules" target="_blank">http://gcc.gnu.org/wiki/cxx-modules</a><br>
<br>
Why is Clang not doing a directory-centric driver-interface? It
seems to obviously solve problems. I wonder if modules can be a
success without coordination between major compiler and buildsystem
developers. That's why I made the git repo - to help work on
something more concrete to see how things scale.<br></div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"></div></div></div><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>'We' (myself & other Clang developers) are/will be talking to GCC folks to try to get consistency here, in one direction or another (maybe some 3rd direction different from Clang or LLVM's). As you noted in a follow-up, there is a directory-based flag in Clang now, added by Boris as he's been working through adding modules support to Build2.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Having just read all of my old posts again, I still worry things
like this will hinder modules 'too much' to be successful. The more
(small) barriers exist, the less chance of success. If modules
aren't successful, then they'll become a poisoned chalice and no one
will be able to work on fixing them. That's actually exactly what I
expect to happen, but I also still hope I'm just missing something
:). I really want to see a committee document from the people
working on modules which actually explores the problems and barriers
to adoption and concludes with 'none of those things matter'. I
think it's fixable, but I haven't seen anyone interested enough to
fix the problems (or even to find out what they are).<br></div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Indeed - hence my desire to talk through these things, get some practical experience, document them to the committee in perhaps a less-ranty, more concrete form along with pros/cons/unknowns/etc to hopefully find some consistency, maybe write up a document of "this is how we expect build systems to integrate with this C++ feature", etc.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<br>
Anyway, you are not here for my rants.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">My current very simplistic prototype, to build a
module file, its respective module object file, and include
those in the library/link for anything that depends on this
library:<br>
<br>
<div><font face="monospace"> add_custom_command(</font></div>
<div><font face="monospace"> COMMAND
${CMAKE_CXX_COMPILER} ${CMAKE_CXX_FLAGS} -xc++ -c -Xclang
-emit-module -fmodules -fmodule-name=Hello
${CMAKE_CURRENT_SOURCE_DIR}/module.modulemap -o
${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm -Xclang
-fmodules-codegen</font></div>
<div><font face="monospace"> DEPENDS module.modulemap
hello.h</font></div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Why does this command depend on hello.h?</div></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>Because it builds the binary module interface (hello_module.pcm) that is a serialized form of the compiler's internal representation of the contents of module.modulemap which refers to hello.h (the modulemap lists the header files that are part of the module). This is all using Clang's current backwards semi-compatible "header modules" stuff. In a "real" modules system, ideally there wouldn't be any modulemap. Just a .cppm file, and any files it depends on (discovered through the build system scanning the module imports, or a compiler-driven .d file style thing).<br><br>Perhaps it'd be better for me to demonstrate something closer to the actual modules reality, rather than this retro header modules stuff that clang supports.<br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> If that is changed and
module.modulemap is not, what will happen?</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>If hello.h is changed and module.modulemap is not changed? The hello_module.pcm does need to be rebuilt.<br><br>Ideally all of this would be implicit (maybe with some flag/configuration, or detected based on new file extensions for C++ interface definitions) in the add_library - taking, let's imagine, the .ccm (let's say, for argument's sake*) file listed in the add_library's inputs and using it to build a .pcm (BMI), building that .pcm as an object file along with all the normal .cc files, <br><br><br>* alternatively, maybe they'll all just be .cc files & a build system would be scanning the .cc files to figure out dependencies & could notice that one of them is the blessed module interface definition based on the first line in the file.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div><font face="monospace"> OUTPUT
${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm</font></div>
<div><font face="monospace"> COMMENT "Generating
hello_module.pcm"</font></div>
<div><font face="monospace"> )</font></div>
<div><font face="monospace"> add_library (Hello hello.cxx
${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)</font></div>
<div><font face="monospace"> target_include_directories(Hello
PUBLIC ${CMAKE_CURRENT_SOURCE_DIR})</font></div>
<div><font face="monospace"> target_compile_options(Hello
PUBLIC -fmodules -Xclang
-fmodule-file=${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm)</font><br>
<br>
(this is based on the example in the CMake docs using
Hello/Demo)<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Good that you got something working.</div><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>This also required one modification to CMake itself to
classify a pcm file as a C++ file that needs to be compiled
(to execute the 3rd line in the basic command list shown
above).<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
An alternative to patching CMake might be <br>
<br>
set_source_files_properties(${CMAKE_CURRENT_BINARY_DIR}/hello_module.pcm
PROPERTIES LANGUAGE CXX)<br>
<br>
though hopefully that is also temporary.</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Ah, thanks! I'll give that a go.<br><br>So I suppose the more advanced question: Is there a way I can extend handling of existing CXX files (and/or define a new kind of file, say, CXXM?) specified in a cc_library. If I want to potentially check if a .cc file is a module, discover its module dependencies, add new rules about how to build those, etc. Is that do-able within my cmake project, or would that require changes to cmake itself? (I'm happy to poke around at what those changes might look like)<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>But this isn't ideal - I don't /think/ I've got the
dependencies quite right & things might not be rebuilding
at the right times.<br>
Also it involves hardcoding a bunch of things like the pcm
file names, header files, etc.<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Indeed. I think part of that comes from the way modules have been
designed. The TS has similar issues.</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><br>Sure - but I'd still be curious to understand how I might go about modifying the build system to handle this. If there are obvious things I have gotten wrong about the dependencies, etc, that would cause this not to rebuild on modifications to any of the source/header files - I'd love any tips you've got.<br><br>& if there are good paths forward for ways to prototype changes to the build system to handle, say, specifying a switch/setting a property/turning on a feature that I could implement that would collect all the .ccm files in an add_library rule and use them to make a .pcm file - I'd be happy to try prototyping that.<br></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div>Ideally, at least for a simplistic build, I wouldn't mind
generating a modulemap from all the .h files (& have those
headers listed in the add_library command - perhaps splitting
public and private headers in some way, only including the
public headers in the module file, likely). Eventually for the
standards-proposal version, it's expected that there won't be
any modulemap file, but maybe all headers are included in the
module compilation (just pass the headers directly to the
compiler).<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
In a design based on passing directories instead of files, would
those directories be redundant with the include directories?<br></div></blockquote><div><br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div>I'm not sure I understand the question, but if I do, I think the answer would be: no, they wouldn't be redundant. The system will not have precompiled modules available to use - because binary module definitions are compiler (& compiler version, and to some degree, compiler flags (eg: are you building this for x86 32 bit or 64 bit?)) dependent.</div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">One of the problems modules adoption will hit is that all the
compilers are designing fundamentally different command line
interfaces for them. </div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>*nod* We'll be working amongst GCC and Clang at least to try to converge on something common.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Buildsystems will have to be rewritten to take
advantage of modules, and they will be annoying to use and adopt.</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>I'm hoping to minimize any rewriting - but also potentially provide recipes for CMake (& other users) as well as patches to CMake itself to help facilitate this.<br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><blockquote type="cite"><div dir="ltr"><div>This also doesn't start to approach the issue of how to
build modules for external libraries - which I'm happy to
discuss/prototype too, though interested in working to
streamline the inter-library but intra-project (not
inter-project) case first.<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
Yes, there are many aspects to consider.<br>
<br>
Are you interested in design of a CMake abstraction for this stuff?
I have thoughts on that, but I don't know if your level of interest
stretches that far.</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Not sure how much work it'd be - at the moment my immediate interest is to show as much real-world/can-actually-run prototype with cmake as possible, either with or without changes to cmake itself (or a combination of minimal cmake changes plus project-specific recipes of how to write a user's cmake files to work with this stuff) or also showing non-working/hypothetical prototypes of what ideal user cmake files would look like with reasonable/viable (but not yet implemented) cmake support.<br></div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">
<blockquote type="cite">
<div dir="ltr">
<div>Stephen - I saw you were asking some questions about this
here ( <a href="https://groups.google.com/a/isocpp.org/forum/#%21topic/modules/sDIYoU8Uljw" target="_blank">https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw</a> &
<a href="https://github.com/steveire/ModulesExperiments" target="_blank">https://github.com/steveire/ModulesExperiments</a> -
didn't really understand how this example applied/worked,
though - I guess maybe it's a prototype syntax proposal?)<br>
</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
It is a set of pre-modules libraries, some of which depend on one
another and with some transitive dependencies in the headers. <br>
<br>
I made it to be 'a few steps above trivial' in the hope that someone
would show me how to port it to modules-ts (even if the result does
not build). So far, no one has. <br></div></blockquote><div><br></div><div>Ah, OK.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">Can you help? It would really help my understanding of where things
currently stand with modules.</div></blockquote><div><br>I can certainly have a go, for sure.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> For example, is there only one way to
port the contents of the cpp files?<br></div></blockquote><div><br>Much like header grouping - how granular headers are (how many headers you have for a given library) is up to the developer to some degree (certain things can't be split up), similarly with modules - given a set of C++ definitions, it's not 100% constrained how those definitions are exposed as modules - the developer has some freedom over how the declarations of those entities are grouped into modules.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">After that, is there one importable module per class or one per
shared library (which I think would make more sense for Qt)?</div></blockquote></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br>Apparently (this was a surprise to me - since I'd been thinking about this based on the Clang header modules (backwards compatibility stuff, not the standardized/new language feature modules)) the thinking is probably somewhere between one-per-class and one-per-shared-library. But for me, in terms of how a build file would interact with this, more than one-per-shared-library is probably the critical tipping point. If it was just one per shared library, then I'd feel like the dependency/flag management would be relatively simple. You have to add a flag to the linker commandline to link in a library, so you have to add a flag to the compile step to reference a module, great. But, no, bit more complicated than that given the finer granularity that's expected here.<br> </div></div></div></div></div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"> And is
transitive dependency expressed in the header files after porting? I
think that last one is dealt with by the 'export import' syntax</div></blockquote><div><br>If you mean one module exposing things from modules it depends on - yes, you can export import. (but by default your imports are just accessible to the implementation of the module)<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">The git repo is an attempt to make the discussion concrete because
it would show how multiple classes and multiple libraries with
dependencies could interact in a modules world. I'm interested in
what it would look like ported to modules-ts, because as far as I
know, clang-modules and module maps would not need porting of the
cpp files at all.</div></blockquote><div><br>Right, clang header-modules is a backwards compatibility feature. It does require a constrained subset of C++ to be used to be effective (ie: basically your headers need to be what we think of as ideal/canonical headers - reincludable, independent, complete, etc). So if you've got good/isolated headers, you can port them to Clang's header modules by adding the module maps & potentially not doing anything else - though, if you rely on not changing your build system, then that presents some problems if you want to scale (more cores) or distribute your build. Because the build system doesn't know about these dependencies - so if you have, say, two .cc files that both include foo.h then bar.h - well, the build system runs two compiles, both compiles try to implicitly build the foo.h module - one blocks waiting for the other to complete, then they continue and block again waiting for bar.h module to be built. If the build system knew about these dependencies (what Google uses - what we call "explicit (header)modules") then it could build the foo.h module and the bar.h module in parallel, then build the two .cc files in parallel.<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<blockquote type="cite">
<div dir="ltr">
<div>Basically: What do folks think about supporting these sort
of features in CMake C++ Builds? Any pointers on how I might
best implement this with or without changes to CMake?</div>
</div>
</blockquote>
<br></div><div text="#000000" bgcolor="#FFFFFF">
I think some design is needed up front. I expect CMake would want to
have a first-class (on equal footing with include directories or
compile definitions and with particular handling) concept for
modules, extending the install(TARGET) command to install module
binary files etc. <br></div></blockquote><div><br></div><div>Module binary files wouldn't be installed in the sense of being part of the shipped package of a library - because module binary files are compiler/flag/etc specific.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF">To do that kind of design, I at least would need to be able to
experiment or conceptualize examples which are not totally trivial,
such as the starting point in my repo. <br>
<br>
On the CMake side, I think something like this should be the target
(note that no compiler command line interface works like this today,
which I think is a barrier to adoption):<br>
<br>
add_library(foo foo.cpp)<br>
<br>
# Target property to enable modules for the target<br>
set_property(TARGET foo PROPERTY USE_CXX_MODULES ON)<br>
<br>
# Note: Use target_include_directories to specify module search<br>
# paths (how GCC and MSVC work)<br>
# Also note: compilers should use the -I paths as a module path
search list so<br>
# that CMake does not have to pass the same list as both -I and as
-fmodule-path=<br>
# or similar entries. <br>
# Also note: This is source compatible with the cmake code that
already exists!<br>
# The existance of /opt/bar/bing.<ext> makes 'import bing;'
work.<br>
target_include_directories(foo PRIVATE /opt/bar)<br>
<br>
# Possibly need a new command to specify headers (there is <br>
# other motivation for this in CMake, so use a generic name without
'modules' in it)<br>
# Because foo has USE_CXX_MODULES ON, foo.h is processed as a
module<br>
# and a binary representation is created for import. Other
properties can <br>
# be set on foo.h with set_source_files_properties() to pass other
command line <br>
# options when generating the module.<br>
target_headers(foo PRIVATE foo.h)<br>
<br>
Also - in the right design, CMake does not have to regenerate
-fmodule-file or whatever into the compile line any time the user
adds 'import something;', which is the case with clang now afaik.
Please correct me if that is not correct.<br>
<br>
I know some people at Kitware have been thinking about modules
though, so I'd be interested in any other insights from there. Brad,
can you comment?<br>
<br>
Here's some other reading material for anyone else following along:<br>
<br>
<a class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-txt-link-freetext" href="https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html" target="_blank">https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html</a><br>
<a class="m_4089600057544350869m_2648820049216965386m_1970699153108696964m_-801848360278511963moz-txt-link-freetext" href="https://build2.org/article/cxx-modules-misconceptions.xhtml" target="_blank">https://build2.org/article/cxx-modules-misconceptions.xhtml</a></div></blockquote><div><br></div><div>Thanks for the links & questions/ideas!<br><br>- Dave</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div text="#000000" bgcolor="#FFFFFF"><br>
<br>
<br>
Thanks,<br>
<br>
Stephen.<br>
<br>
</div>
</blockquote></div></div></div></div></div>