I think this discussion is more suited to the cmake-developers mailing
list. Moving there. Hopefully Brad or someone else can provide other
input from research already done.
On 05/07/2018 12:49 AM, David Blaikie wrote:
>
>> The basic commands required are:
>>
>> clang++ -fmodules -xc++ -Xclang -emit-module -Xclang
>> -fmodules-codegen -fmodule-name=foo foo.modulemap -o foo.pcm
>> clang++ -fmodules -c -fmodule-file=foo.pcm use.cpp
>> clang++ -c foo.pcm
>> clang++ foo.o use.o -o a.out
>
> 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.
>
> 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?
>
>
> - 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.
Perhaps it would be interesting to get an idea of how often users need
to change their buildsystems because of a new link dependency, and how
often users add includes to existing c++ files.
I expect you'll find the latter to be a far bigger number.
I also expect that expecting users to edit their buildsystem, or allow
it to be regenerated every time they add/remove includes would lead to
less adoption of modules. I can see people trying them and then giving
up in frustration.
I think I read somewhere that the buildsystem in google already requires
included '.h' files to be listed explicitly in the buildsystem, so it's
no change in workflow there. For other teams, that would be a change
which could be a change in workflow and something rebelled against.
By the way, do you have any idea how much modules adoption would be
needed to constitute "success"? Is there a goal there?
> 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?
> 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.
Fair enough.
>
>
> 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.
>
>
> 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.
Perhaps. I'd be interested in how far into the book such a system would
take a beginner. Maybe that's fine, I don't know. Such a system might
not help with code in stack overflow questions/answers though, which
would probably be simpler sticking with includes (eg for Qt/boost).
Library authors will presumably have some say, or try to introduce some
'best practice' for users to follow. And such best practice will be
different for each library.
>
>
> I raised some of these issues a few years ago regarding the clang
> implementation with files named exactly module.modulemap:
>
>
> 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-td4041946i20.html
>
> Interestingly, GCC is taking a directory-centric approach in the
> driver (-fmodule-path=) as opposed to the 'add a file to your
> compile line for each import' that Clang and MSVC are taking:
>
> http://gcc.gnu.org/wiki/cxx-modules
>
> Why is Clang not doing a directory-centric driver-interface? It
> seems to obviously so
