Thanks! That is the message I missed - I filled the doodle poll.
Now, integrated in my calendar.

— Gaby

On Mar 11, 2019, at 9:23 AM, Tom Honermann <> wrote:

Invites were sent to the Tooling mailing list.  See  If you are unable to extract the .ics files from that link, let me know and I'll forward the original email to you.


On 3/11/19 12:12 PM, Gabriel Dos Reis via Modules wrote:

 I missed the announcement that March 8 was the meeting date - can’t find the announcement in my mailbox :-/

— Gaby

On Mar 11, 2019, at 6:13 AM, Ben Craig <> wrote:

Sending this to both the modules and the tooling list, as the tooling list has been having lots of technical trouble lately.  Actual notes below the break…




Minute Taker: Ben Craig



Ben Craig

Bryce Lelbach

Izzy Muerte

Olga Arhipova (Microsoft)

Ben Boeckel (Kitware)

Boris Kolpackov (build2)

Rene Rivera

Richard Smith

Tom Honermann

Mark Zeren

Christof Meerwalk

Bruno Lopes

JF Bastien

Michael Spencer

Mathias Stearn

Corentin Jabot

Peter Bindels

Steve Downey



Bryce: When should we have a TR go out?

Mathias: Prefer to release it at the same time as the IS so that we have usage recommendation at the same time as we have the IS support

Tom: Agree with Mathias, but not too concerned about the time.  Let's work on it now and see when it is ready.


Rene Rivera: Just saying that the argument for delaying the TR would also apply to not having modules in 20.


Mathias Stearn:  Yes, but since modules are currently in for 20, they should be useable when released. I think the TR is a major component of the usability story


Olga: Hoping the doc evolves beyond C++20.  It would be ideal for us to know everything, and we will get something useful, but hopefully we can evolve it past that.


Bryce: open question: can a TR be a living document? Can it be evolved?


Mathias: I think we can do versions, but probably not a live-at-head document.


Rene: I just want to say that doing releases of it are best.


Bryce: Let's assume that an ISO TR is the right kind of document.


Corentin: There is no way we can do everything we want by the time C++20 is released.  We should aim for a first release that is minimal.  Maybe aim for more complete by C++21 or so.  The document needs to give a set of good practices and bad practices.  If module names don't match files, we can't change that, so we need to discourage that practice.


Tom: Maybe today we can establish a priority list of things to address in the TR.


Bryce: Just because the standard is out at C++20 doesn't mean that implementations will be available in C++20


Steve: The full standard may not be out in 2020, but people will start to want to work with them now in /std:c++2a modes.


Mathias: All the big compilers have early implementations


Bryce: Work on defining scope, priorities, and goals for the Technical Report.


Between now and next meeting, we will collate that list of things and try to prioritize those things.


Ben Craig:  Stakeholders that should be considered are compiler vendors, build tool vendors, library vendors end users


Bryce: Should consider, and determine if package vendors are in scope (like system package managers).


Ben Boeckel: Need to determine where package managers should put module interface units.  That may be the extent of their involvement.


Rene: If you make it clear what modules are not meant to cover, then we can scope better


Tom: Don't forget Swig, static analyzers.


Bryce: Agreed.  Splitting build system vendors and tool vendors.


corentin: Distribution maintainers seems more accurate

ben.boeckel: depends on what you call anaconda, nix, and ports

Mathias: Maybe foreign function interfaces?  May be out of scope?

Bryce: Unsure if it falls into one of these categories


JF: For Clang modules, we've been bridging between objective C and C++.


Olga: MSVC also considers modules as a way to interact with other languages


Mathias: Other languages may also produce modules to be consumed by C++



corentin:  I think I'd call them distribution too to avoid confusion with package

Steve Downey:  filesystem hierarchy maintainers is more the case than distro maintainers. At least for first cut.

ben.boeckel:  yes, thats linux-centric, but anything which deals with install prefixes cares

Steve Downey:  BSD has a similar set of rules. Posix-ish

ben.boeckel:  theyll get ports since bsd is C for the long term


Bryce: What list of concrete open questions should we address?

Example: Is shipping prebuild BMIs best practice


Mathias Stearn:  Should these be a list of use-cases we want to address rather than questions?


Boris Kolpackov:  Here are some ideas on describing modular libraries in .pc (pkg-config) files:


Boeckel: my first thoughts on cmake's iface:



Boeckel: Build tools that know about modules.  Old build tools that don't.  How do we tell compilers about modules (i.e. module maps).  How to consume a library via modules (i.e. pkgconfig).  pkgconfig tells me -I and -L flags.  How do I convey that information?  Specification of available modules from an install.


Tom: What do we need to do to enable adoption?  How can we adhere to what people do today?


Steve: How do I say something is eligible to be a header unit?  How do I say where the interface for a module lives?  When can a #include be converted to an import <foo>?


Corentin: How do we avoid conflicts between module names?  How do we maintain ABI with modules?

Bryce: Module ABI has multiple models of ownership.  We'll need to discuss it at some point.


Mathias Stearn:  How close can we get to having modules be “self-descriptive” rather than relying on pkg-conf


ben.boeckel:  would generating the pkg-conf from the source be sufficiently self-descriptive for you?


Mathias Stearn:  I meant as a distribution format. If module interface sources are distributed as archive files (still not agreed on, but the more I lthink about it, the more I like it), we can easily include as much metadata in any format we want. At that point, I don’t think there is an advantage to shoehorning the metadata into pkg-conf is useful


ben.boeckel: you might still need to know where to look for those files and their module name (if, e.g., you have a ácceñt module name on Windows)


Michael Spencer: The distribution format for module interfaces may as well be text.


Mathias Stearn:  Sure, but the same is true of the .pc files. My issue with .pc is that I don’t think actual compile flags are the best way to convey metadata


ben.boeckel:  it wouldnt contain compile flags, but the same info that cmake stores in its usage requirements

makeing the actual flags and rules is up to the consumer of the .pc file

boris and i have *very* similar ideas here based on what i see in his link


Boris Kolpackov:  yeah, looks pretty similar


Mathias Stearn:  @michael, in that situation, would you have each module unit distributed in separate files, even for libs with 100’s of internal module partitions?


Michael Spencer:  Yeah


Mathias Stearn:  (I know that is what we do today, so it wouldn’t be much worse, this just seems like a reasonable thing to improve upon)


ben.boeckel:  a tool to take a module file and 100 partitions and output a single miu would be useful

but can be done in the future

id like to see such a tool first before we try specifying it





Ben Craig: How can we best exploit modules long term?


Olga: Maybe group these into questions per stakeholder?


Tom: Multiple models for consuming modules.  Separate compilation vs. textual inclusion.  With separate compilation, you can get conflicting options.  What kind of guidance do we give to avoid those conflicts so that the textual inclusion model can work.  How do we deal with conflicts between the options that producers and consumers use and the impact to the ability to support a textual inclusion model?


Mathias: Not sure if it is technically possible to support textual inclusion

Tom: Good discussion to have at some other time.


Bruno: How do we teach people to migrate to modules?  When do we suggest to use old #include, vs header units, vs modules.


Steve: What are the techniques for fixing your code so that it can be modular?  May be out of scope.  Cycle breaking for example.


Tom: How do people write headers that work for both C++20 and C++17?  While still being modular?


Corentin: How big should modules be?  What makes them too big, too small?


Bryce: Modules are scalable in clang and that big modules are fine?

Richard: They are scalable, and they might be more efficient.

Bryce: Is that expected to be true of all implementations?

Richard: Unclear if it will be true for all implementations.


Rene: We should be sure to stick to tooling as much as possible and not to get too much into software design.


Mathias: @rene perhaps observations might work as notes in the tr?

From Rene RIvera to Everyone: sure

Note this is only for the software design POV. Prescribing for tooling is fine.


Michael Spencer to Everyone:  It wouldn't be crazy to have a single text file represent multiple modules, it's just more non standard extensions to do it.

ben.boeckel to Everyone:  yeah, but we can include "heres timings for project X using {tiny,large} modules for {new,old} build systems"



Olga: From the users perspective, libraries will create modules.  From the build perspective it isn't a question of how big one module is, but how many modules and how long of a dependency chain do you have.  This is what will affect the build throughput the most.


Bryce: Specific use cases to address?


Tom: Existing build systems need to be able to consume modules, with minimal updates.  Only updating flags.

* CMake

* Make

* Boost Build

* Internal company build systems

* autoconf

* Meson

* ninja

* shell scripts

* scons

* waf

* Bazel

* Buck

* Cargo

* Gulp

* WebPack

* Ant

* llbuild

* Evoke

* msbuild

* qbs


Mathias Stearn:  As a user of scons, I *don’t* want scons to support modules so I have yet another reason to move off of it :)

corentin: we should make a not in the tr that waf is not supported

ben.boeckel:  isnt waf just a scons fork and stripped down?

my only experience is via mpv where its decent (but also a c-only project)

decent (but also a c-only project)

anotehr build tool: qmake



Steve: Use case: Hello world with modules


Olga: Just building module interfaces for tooling purposes.  Code completion.


Mathias: Distributed builds (high bandwidth + high latency, and low bandwidth + low latency environments)


* IceCC

* IncrediBuild

* sccache

* ccache

* distcc

* Bezel remote build execution

* My company's interneal distributed build systems.


Mathias: What does an ideal one look like?


Tom: Static analysis tools, where source code is paramount.  Comments get used sometime.

* Coverity

* Clang static analysis

* Grammatech (Aaron Ballman)

* CppCheck


Incremental Builds


Dependency scanning vs. explicit explicit module dependency example

* Side by side example where one version uses scanning, other uses explicit deps


Tom: Other tools that traditionally operate on a single TU


* clang tooling

* castXML

* Qt Moc

* Test mocking frameworks

   * Google mocks


Things that generate code (out of scope?):

   * protobuf


corentin: mixed build systems

   Ex: CMake and QMake in the same build

   More likely Cmake + lots of automake



Steve: Internal vs. external modules (things from my project vs. out of my project)


Steve: Bug reporting tools, like Creduce, delta


Header only libraries




Boeckel: Provide #includes for backwards compat


Corentin: Cuda, vulkan, openCL, SYCL





corentin:  tom : why not attributes rather than comments?


ben.boeckel: cocinelle?

though its mostly pattern matching anyways afaik


Mathias Stearn:  I’m currently thinking GigE/same-switch LAN vs 10GigE/short-distance WAN


olgaark:  Internal dispributed builds (MS and others have it)


ben.boeckel:  static analysis: viva64


Mark Zeren:  (if you build tensor flow, at least until it ports to swift...)


Bruno Lopes:  GCCXML


ben.boeckel:  superceded by castxml :)


Mathias Stearn:  Won’t anything using clang-tooling JustWork with modules with something like -frewrite-imports?


ben.boeckel:  swig reads and writes c++; protobuf writes it


Mathias Stearn:  I was thinking of it similarish to nim-lang which compile to C++ source among other targets


tom:  Mathias, maybe?  So long as BMIs aren't shared between tools/compilers built with incompatible Clang versions.


Mathias Stearn:  I think -frewrite-imports is a BMI-free solution

@Bruno, can you confirm?


tom:  -frewrite-imports might consume an existing BMI.


Bruno Lopes:  it could, but it doesn't need to

Modules mailing list
Link to this post:;;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&amp;reserved=0

Modules mailing list
Link to this post: