Invites were sent to the Tooling mailing list. See
http://www.open-std.org/pipermail/tooling/2019-March/000500.html. If you
are unable to extract the .ics files from that link, let me know and
I'll forward the original email to you.

Tom.

On 3/11/19 12:12 PM, Gabriel Dos Reis via Modules wrote:
> Thanks!
>
> 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 <ben.craig_at_[hidden]
> <mailto:ben.craig_at_[hidden]>> 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
>>
>> 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
>>
>> _______________________________________________
>> Modules mailing list
>> Modules_at_[hidden] <mailto:Modules_at_[hidden]>
>> Subscription:
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3I0FUiH3dTqgwuEPP7VY%2BPiCSeuZatZeHLO8DMiHMho%3D&amp;reserved=0
>> Link to this post:
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0240.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&amp;reserved=0
>
> _______________________________________________
> Modules mailing list
> Modules_at_[hidden]
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/03/0241.php