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

Attendees:
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: https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules-install

Boeckel: my first thoughts on cmake's iface: https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/blob/master/header-units/external/CMakeLists.txt


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)
* FastBUILD
* 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
* SWIG
* 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

Boost

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