<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">On 04/20/2018 01:39 AM, David Blaikie
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
Great! Thanks for reaching out. Sorry it has taken me a while to
respond. Have you had other response off-list?<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
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>
<br>
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>
<br>
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? Even more complication for my buildsystem. Do I have
to wait for my dependencies to modularize bottom-up before I can
benefit from modules? 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?<br>
<br>
I raised some of these issues a few years ago regarding the clang
implementation with files named exactly module.modulemap:<br>
<br>
<a class="moz-txt-link-freetext"
href="http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html">http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946.html</a><br>
<br>
<a class="moz-txt-link-freetext"
href="http://clang-developers.42468.n3.nabble.com/How-do-I-try-out-C-modules-with-clang-td4041946i20.html">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="moz-txt-link-freetext"
href="http://gcc.gnu.org/wiki/cxx-modules">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>
<br>
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>
<br>
Anyway, you are not here for my rants.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
Why does this command depend on hello.h? If that is changed and
module.modulemap is not, what will happen?<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
Good that you got something working.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
Indeed. I think part of that comes from the way modules have been
designed. The TS has similar issues.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
In a design based on passing directories instead of files, would
those directories be redundant with the include directories?<br>
<br>
One of the problems modules adoption will hit is that all the
compilers are designing fundamentally different command line
interfaces for them. Buildsystems will have to be rewritten to take
advantage of modules, and they will be annoying to use and adopt.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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"
moz-do-not-send="true">https://groups.google.com/a/isocpp.org/forum/#!topic/modules/sDIYoU8Uljw</a> &
<a href="https://github.com/steveire/ModulesExperiments"
moz-do-not-send="true">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>
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>
<br>
Can you help? It would really help my understanding of where things
currently stand with modules. For example, is there only one way to
port the contents of the cpp files?<br>
<br>
After that, is there one importable module per class or one per
shared library (which I think would make more sense for Qt)? And is
transitive dependency expressed in the header files after porting? I
think that last one is dealt with by the 'export import' syntax<br>
<br>
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.<br>
<br>
<blockquote type="cite"
cite="mid:CAENS6EsNOqOS-tB=7CmDtgDTFiy0jxD8X9VS3ADBc7G5P0DLcQ@mail.gmail.com">
<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>
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>
<br>
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="moz-txt-link-freetext"
href="https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html">https://izzys.casa/posts/millennials-are-killing-the-modules-ts.html</a><br>
<a class="moz-txt-link-freetext"
href="https://build2.org/article/cxx-modules-misconceptions.xhtml">https://build2.org/article/cxx-modules-misconceptions.xhtml</a><br>
<br>
<br>
Thanks,<br>
<br>
Stephen.<br>
<br>
</body>
</html>