[Tooling] [isocpp-modules] March 8 SG15 minutes

Tom Honermann tom at honermann.net
Mon Mar 11 17:23:08 CET 2019


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 ni.com 
> <mailto:ben.craig at ni.com>> 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 lists.isocpp.org <mailto:Modules at lists.isocpp.org>
>> 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 lists.isocpp.org
> Subscription: http://lists.isocpp.org/mailman/listinfo.cgi/modules
> Link to this post: http://lists.isocpp.org/modules/2019/03/0241.php


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/tooling/attachments/20190311/da79dc8e/attachment-0001.html 


More information about the Tooling mailing list