<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body dir="auto">
<div dir="ltr"></div>
<div dir="ltr">Thanks! That is the message I missed - I filled the doodle poll.</div>
<div dir="ltr">Now, integrated in my calendar.</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">— Gaby</div>
<div dir="ltr"><br>
On Mar 11, 2019, at 9:23 AM, Tom Honermann &lt;<a href="mailto:tom@honermann.net">tom@honermann.net</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div class="moz-cite-prefix">Invites were sent to the Tooling mailing list.&nbsp; See <a class="moz-txt-link-freetext" href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.open-std.org%2Fpipermail%2Ftooling%2F2019-March%2F000500.html&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936238432&amp;sdata=bq%2BVEvpAYbjmzmZZLyCYtntJ7ExiFWdQ4Y%2BRuToZFDU%3D&amp;reserved=0" originalsrc="http://www.open-std.org/pipermail/tooling/2019-March/000500.html" shash="eV5KkPEUggO8GJ9t2u8PIhphSnjItDFK5kpJ/734vBt3aBkAgFsuao56RwvTh7IR09Pdp9rqpnchygounvlDXMRNumSmkIIuNHxblapZI4f79H138jeJJg521GWgYsYWR88S9ovpLM7nn3LGRUur4/6RvkUykgGgbY&#43;VnZRc7Zs=">
http://www.open-std.org/pipermail/tooling/2019-March/000500.html</a>.&nbsp; If you are unable to extract the .ics files from that link, let me know and I'll forward the original email to you.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Tom.<br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 3/11/19 12:12 PM, Gabriel Dos Reis via Modules wrote:<br>
</div>
<blockquote type="cite" cite="mid:E9F7A1EB-B7B7-4181-89E5-93ED760D1FF8@microsoft.com">
<div dir="ltr">Thanks!&nbsp;</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">&nbsp;I missed the announcement that March 8 was the meeting date - can’t find the announcement in my mailbox :-/</div>
<div dir="ltr"><br>
</div>
<div dir="ltr">— Gaby</div>
<div dir="ltr"><br>
On Mar 11, 2019, at 6:13 AM, Ben Craig &lt;<a href="mailto:ben.craig@ni.com" moz-do-not-send="true">ben.craig@ni.com</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<meta name="Generator" content="Microsoft Word 15 (filtered
            medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        margin-bottom:.0001pt;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
        {mso-style-priority:99;
        color:#954F72;
        text-decoration:underline;}
span.EmailStyle17
        {mso-style-type:personal-compose;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div class="WordSection1">
<p class="MsoNormal">Sending this to both the modules and the tooling list, as the tooling list has been having lots of technical trouble lately.&nbsp; Actual notes below the break…<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div style="mso-element:para-border-div;border:none;border-bottom:double
              windowtext 2.25pt;padding:0in 0in 1.0pt 0in">
<p class="MsoNormal" style="border:none;padding:0in"><o:p>&nbsp;</o:p></p>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Minute Taker: Ben Craig<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Attendees:<o:p></o:p></p>
<p class="MsoNormal">Ben Craig<o:p></o:p></p>
<p class="MsoNormal">Bryce Lelbach<o:p></o:p></p>
<p class="MsoNormal">Izzy Muerte<o:p></o:p></p>
<p class="MsoNormal">Olga Arhipova (Microsoft)<o:p></o:p></p>
<p class="MsoNormal">Ben Boeckel (Kitware)<o:p></o:p></p>
<p class="MsoNormal">Boris Kolpackov (build2)<o:p></o:p></p>
<p class="MsoNormal">Rene Rivera<o:p></o:p></p>
<p class="MsoNormal">Richard Smith<o:p></o:p></p>
<p class="MsoNormal">Tom Honermann<o:p></o:p></p>
<p class="MsoNormal">Mark Zeren<o:p></o:p></p>
<p class="MsoNormal">Christof Meerwalk<o:p></o:p></p>
<p class="MsoNormal">Bruno Lopes<o:p></o:p></p>
<p class="MsoNormal">JF Bastien<o:p></o:p></p>
<p class="MsoNormal">Michael Spencer<o:p></o:p></p>
<p class="MsoNormal">Mathias Stearn<o:p></o:p></p>
<p class="MsoNormal">Corentin Jabot<o:p></o:p></p>
<p class="MsoNormal">Peter Bindels<o:p></o:p></p>
<p class="MsoNormal">Steve Downey<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: When should we have a TR go out?<o:p></o:p></p>
<p class="MsoNormal">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<o:p></o:p></p>
<p class="MsoNormal">Tom: Agree with Mathias, but not too concerned about the time.&nbsp; Let's work on it now and see when it is ready.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Rene Rivera: Just saying that the argument for delaying the TR would also apply to not having modules in 20.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; 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<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Olga: Hoping the doc evolves beyond C&#43;&#43;20.&nbsp; It would be ideal for us to know everything, and we will get something useful, but hopefully we can evolve it past that.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: open question: can a TR be a living document? Can it be evolved?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: I think we can do versions, but probably not a live-at-head document.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Rene: I just want to say that doing releases of it are best.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Let's assume that an ISO TR is the right kind of document.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Corentin: There is no way we can do everything we want by the time C&#43;&#43;20 is released.&nbsp; We should aim for a first release that is minimal.&nbsp; Maybe aim for more complete by C&#43;&#43;21 or so.&nbsp; The document needs to give a set of good practices and
 bad practices.&nbsp; If module names don't match files, we can't change that, so we need to discourage that practice.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Maybe today we can establish a priority list of things to address in the TR.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Just because the standard is out at C&#43;&#43;20 doesn't mean that implementations will be available in C&#43;&#43;20<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: The full standard may not be out in 2020, but people will start to want to work with them now in /std:c&#43;&#43;2a modes.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: All the big compilers have early implementations<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Work on defining scope, priorities, and goals for the Technical Report.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Between now and next meeting, we will collate that list of things and try to prioritize those things.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Ben Craig:&nbsp; Stakeholders that should be considered are compiler vendors, build tool vendors, library vendors end users<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Should consider, and determine if package vendors are in scope (like system package managers).<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Ben Boeckel: Need to determine where package managers should put module interface units.&nbsp; That may be the extent of their involvement.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Rene: If you make it clear what modules are not meant to cover, then we can scope better<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Don't forget Swig, static analyzers.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Agreed.&nbsp; Splitting build system vendors and tool vendors.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">corentin: Distribution maintainers seems more accurate<o:p></o:p></p>
<p class="MsoNormal">ben.boeckel: depends on what you call anaconda, nix, and ports<o:p></o:p></p>
<p class="MsoNormal">Mathias: Maybe foreign function interfaces?&nbsp; May be out of scope?<o:p></o:p></p>
<p class="MsoNormal">Bryce: Unsure if it falls into one of these categories<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">JF: For Clang modules, we've been bridging between objective C and C&#43;&#43;.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Olga: MSVC also considers modules as a way to interact with other languages<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: Other languages may also produce modules to be consumed by C&#43;&#43;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">corentin:&nbsp; I think I'd call them distribution too to avoid confusion with package<o:p></o:p></p>
<p class="MsoNormal">Steve Downey:&nbsp; filesystem hierarchy maintainers is more the case than distro maintainers. At least for first cut.<o:p></o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; yes, thats linux-centric, but anything which deals with install prefixes cares<o:p></o:p></p>
<p class="MsoNormal">Steve Downey:&nbsp; BSD has a similar set of rules. Posix-ish<o:p></o:p></p>
<p class="MsoNormal">ben.boeckel: &nbsp;theyll get ports since bsd is C for the long term<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: What list of concrete open questions should we address?<o:p></o:p></p>
<p class="MsoNormal">Example: Is shipping prebuild BMIs best practice<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; Should these be a list of use-cases we want to address rather than questions?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boris Kolpackov:&nbsp; Here are some ideas on describing modular libraries in .pc (pkg-config) files:
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbuild2.org%2Fbuild2%2Fdoc%2Fbuild2-build-system-manual.xhtml%23cxx-modules-install&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936248444&amp;sdata=tp4hXoMcBeg5WAcSu3AG4rXihxfPQ55GwEa%2BYVN9dSs%3D&amp;reserved=0" originalsrc="https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules-install" shash="jpG2hpr6MHjLg6y8k/ky1bMZ8VDNzvpLC7jcTbgpB1Dn3zvMVVXgxBwe&#43;UajaR8prjtjj8Jx3linivg3O&#43;TIZt1iaWPezyKqsmRh8j&#43;EPs0sUANkMuCe4tDd&#43;5aUWsKnGs7o123TknzWGr3WDu5mYMUAu/Osb4DAhBpTXtnR1lw=" moz-do-not-send="true">
https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules-install</a><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boeckel: my first thoughts on cmake's iface: <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgitlab.kitware.com%2Fben.boeckel%2Fcxx-modules-sandbox%2Fblob%2Fmaster%2Fheader-units%2Fexternal%2FCMakeLists.txt&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936258452&amp;sdata=xnuU%2B6DUAi2Zj7wGhPD8Dqh6Qj7aDkg8WXieHpFX6lQ%3D&amp;reserved=0" originalsrc="https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/blob/master/header-units/external/CMakeLists.txt" shash="UAkiKYJ6alFgfPyKaQKzf4VVi5aW5p9UYj4mdGqBGsqmaGyQfl2mRQDdVL20TuETEXYtYz5J2W4L1V6XekJMmn3yB3brLOeNPStkvMURRhbnJoNmagu97OBFgcQPs4mq71aDP6hxAg/iGEwfNTTAlub5bHp4&#43;c2z92vr5PqhPrI=" moz-do-not-send="true">
https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/blob/master/header-units/external/CMakeLists.txt</a><o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boeckel: Build tools that know about modules.&nbsp; Old build tools that don't.&nbsp; How do we tell compilers about modules (i.e. module maps).&nbsp; How to consume a library via modules (i.e. pkgconfig).&nbsp; pkgconfig tells me -I and -L flags.&nbsp; How do
 I convey that information?&nbsp; Specification of available modules from an install.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: What do we need to do to enable adoption?&nbsp; How can we adhere to what people do today?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: How do I say something is eligible to be a header unit?&nbsp; How do I say where the interface for a module lives?&nbsp; When can a #include be converted to an import &lt;foo&gt;?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Corentin: How do we avoid conflicts between module names?&nbsp; How do we maintain ABI with modules?<o:p></o:p></p>
<p class="MsoNormal">Bryce: Module ABI has multiple models of ownership.&nbsp; We'll need to discuss it at some point.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; How close can we get to having modules be “self-descriptive” rather than relying on pkg-conf<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; would generating the pkg-conf from the source be sufficiently self-descriptive for you?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; 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<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">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)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Michael Spencer: The distribution format for module interfaces may as well be text.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; 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<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; it wouldnt contain compile flags, but the same info that cmake stores in its usage requirements<o:p></o:p></p>
<p class="MsoNormal">makeing the actual flags and rules is up to the consumer of the .pc file<o:p></o:p></p>
<p class="MsoNormal">boris and i have *very* similar ideas here based on what i see in his link<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boris Kolpackov:&nbsp; yeah, looks pretty similar<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; @michael, in that situation, would you have each module unit distributed in separate files, even for libs with 100’s of internal module partitions?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Michael Spencer:&nbsp; Yeah<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; (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)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; a tool to take a module file and 100 partitions and output a single miu would be useful<o:p></o:p></p>
<p class="MsoNormal">but can be done in the future<o:p></o:p></p>
<p class="MsoNormal">id like to see such a tool first before we try specifying it<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Ben Craig: How can we best exploit modules long term?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Olga: Maybe group these into questions per stakeholder?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Multiple models for consuming modules.&nbsp; Separate compilation vs. textual inclusion.&nbsp; With separate compilation, you can get conflicting options.&nbsp; What kind of guidance do we give to avoid those conflicts so that the textual inclusion
 model can work.&nbsp; 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?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: Not sure if it is technically possible to support textual inclusion<o:p></o:p></p>
<p class="MsoNormal">Tom: Good discussion to have at some other time.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bruno: How do we teach people to migrate to modules?&nbsp; When do we suggest to use old #include, vs header units, vs modules.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: What are the techniques for fixing your code so that it can be modular?&nbsp; May be out of scope.&nbsp; Cycle breaking for example.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: How do people write headers that work for both C&#43;&#43;20 and C&#43;&#43;17?&nbsp; While still being modular?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Corentin: How big should modules be?&nbsp; What makes them too big, too small?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Modules are scalable in clang and that big modules are fine?<o:p></o:p></p>
<p class="MsoNormal">Richard: They are scalable, and they might be more efficient.<o:p></o:p></p>
<p class="MsoNormal">Bryce: Is that expected to be true of all implementations?<o:p></o:p></p>
<p class="MsoNormal">Richard: Unclear if it will be true for all implementations.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Rene: We should be sure to stick to tooling as much as possible and not to get too much into software design.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: @rene perhaps observations might work as notes in the tr?<o:p></o:p></p>
<p class="MsoNormal">From Rene RIvera to Everyone: sure<o:p></o:p></p>
<p class="MsoNormal">Note this is only for the software design POV. Prescribing for tooling is fine.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Michael Spencer to Everyone:&nbsp; It wouldn't be crazy to have a single text file represent multiple modules, it's just more non standard extensions to do it.<o:p></o:p></p>
<p class="MsoNormal">ben.boeckel to Everyone:&nbsp; yeah, but we can include &quot;heres timings for project X using {tiny,large} modules for {new,old} build systems&quot;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Olga: From the users perspective, libraries will create modules.&nbsp; 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.&nbsp; This is what will affect the
 build throughput the most.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bryce: Specific use cases to address?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Existing build systems need to be able to consume modules, with minimal updates.&nbsp; Only updating flags.<o:p></o:p></p>
<p class="MsoNormal">* CMake<o:p></o:p></p>
<p class="MsoNormal">* Make<o:p></o:p></p>
<p class="MsoNormal">* Boost Build<o:p></o:p></p>
<p class="MsoNormal">* Internal company build systems<o:p></o:p></p>
<p class="MsoNormal">* autoconf<o:p></o:p></p>
<p class="MsoNormal">* Meson<o:p></o:p></p>
<p class="MsoNormal">* ninja<o:p></o:p></p>
<p class="MsoNormal">* shell scripts<o:p></o:p></p>
<p class="MsoNormal">* scons<o:p></o:p></p>
<p class="MsoNormal">* waf<o:p></o:p></p>
<p class="MsoNormal">* Bazel<o:p></o:p></p>
<p class="MsoNormal">* Buck<o:p></o:p></p>
<p class="MsoNormal">* Cargo<o:p></o:p></p>
<p class="MsoNormal">* Gulp<o:p></o:p></p>
<p class="MsoNormal">* WebPack<o:p></o:p></p>
<p class="MsoNormal">* Ant<o:p></o:p></p>
<p class="MsoNormal">* llbuild<o:p></o:p></p>
<p class="MsoNormal">* Evoke<o:p></o:p></p>
<p class="MsoNormal">* msbuild<o:p></o:p></p>
<p class="MsoNormal">* qbs<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; As a user of scons, I *don’t* want scons to support modules so I have yet another reason to move off of it :)<o:p></o:p></p>
<p class="MsoNormal">corentin: we should make a not in the tr that waf is not supported<o:p></o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; isnt waf just a scons fork and stripped down?<o:p></o:p></p>
<p class="MsoNormal">my only experience is via mpv where its decent (but also a c-only project)<o:p></o:p></p>
<p class="MsoNormal">decent (but also a c-only project)<o:p></o:p></p>
<p class="MsoNormal">anotehr build tool: qmake<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: Use case: Hello world with modules<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Olga: Just building module interfaces for tooling purposes.&nbsp; Code completion.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: Distributed builds (high bandwidth &#43; high latency, and low bandwidth &#43; low latency environments)<o:p></o:p></p>
<p class="MsoNormal">* FastBUILD<o:p></o:p></p>
<p class="MsoNormal">* IceCC<o:p></o:p></p>
<p class="MsoNormal">* IncrediBuild<o:p></o:p></p>
<p class="MsoNormal">* sccache<o:p></o:p></p>
<p class="MsoNormal">* ccache<o:p></o:p></p>
<p class="MsoNormal">* distcc<o:p></o:p></p>
<p class="MsoNormal">* Bezel remote build execution<o:p></o:p></p>
<p class="MsoNormal">* My company's interneal distributed build systems.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias: What does an ideal one look like?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Static analysis tools, where source code is paramount.&nbsp; Comments get used sometime.<o:p></o:p></p>
<p class="MsoNormal">* Coverity<o:p></o:p></p>
<p class="MsoNormal">* Clang static analysis<o:p></o:p></p>
<p class="MsoNormal">* Grammatech (Aaron Ballman)<o:p></o:p></p>
<p class="MsoNormal">* CppCheck<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Incremental Builds<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Dependency scanning vs. explicit explicit module dependency example<o:p></o:p></p>
<p class="MsoNormal">* Side by side example where one version uses scanning, other uses explicit deps<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Tom: Other tools that traditionally operate on a single TU<o:p></o:p></p>
<p class="MsoNormal">* SWIG<o:p></o:p></p>
<p class="MsoNormal">* clang tooling<o:p></o:p></p>
<p class="MsoNormal">* castXML<o:p></o:p></p>
<p class="MsoNormal">* Qt Moc<o:p></o:p></p>
<p class="MsoNormal">* Test mocking frameworks<o:p></o:p></p>
<p class="MsoNormal">&nbsp;&nbsp; * Google mocks<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Things that generate code (out of scope?):<o:p></o:p></p>
<p class="MsoNormal">&nbsp;&nbsp; * protobuf<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">corentin: mixed build systems<o:p></o:p></p>
<p class="MsoNormal">&nbsp;&nbsp; Ex: CMake and QMake in the same build<o:p></o:p></p>
<p class="MsoNormal">&nbsp;&nbsp; More likely Cmake &#43; lots of automake<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: Internal vs. external modules (things from my project vs. out of my project)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Steve: Bug reporting tools, like Creduce, delta<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Header only libraries<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boost<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Boeckel: Provide #includes for backwards compat<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Corentin: Cuda, vulkan, openCL, SYCL<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">corentin:&nbsp; tom : why not attributes rather than comments?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel: cocinelle?<o:p></o:p></p>
<p class="MsoNormal">though its mostly pattern matching anyways afaik<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; I’m currently thinking GigE/same-switch LAN vs 10GigE/short-distance WAN<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">olgaark:&nbsp; Internal dispributed builds (MS and others have it)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; static analysis: viva64<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mark Zeren:&nbsp; (if you build tensor flow, at least until it ports to swift...)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bruno Lopes:&nbsp; GCCXML<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; superceded by castxml :)<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; Won’t anything using clang-tooling JustWork with modules with something like -frewrite-imports?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">ben.boeckel:&nbsp; swig reads and writes c&#43;&#43;; protobuf writes it<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; I was thinking of it similarish to nim-lang which compile to C&#43;&#43; source among other targets<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">tom:&nbsp; Mathias, maybe?&nbsp; So long as BMIs aren't shared between tools/compilers built with incompatible Clang versions.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Mathias Stearn:&nbsp; I think -frewrite-imports is a BMI-free solution<o:p></o:p></p>
<p class="MsoNormal">@Bruno, can you confirm?<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">tom:&nbsp; -frewrite-imports might consume an existing BMI.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Bruno Lopes:&nbsp; it could, but it doesn't need to<o:p></o:p></p>
</div>
</div>
</blockquote>
<blockquote type="cite">
<div dir="ltr"><span>_______________________________________________</span><br>
<span>Modules mailing list</span><br>
<span><a href="mailto:Modules@lists.isocpp.org" moz-do-not-send="true">Modules@lists.isocpp.org</a></span><br>
<span>Subscription: <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936258452&amp;sdata=qgH%2F2EVXHW8YzJgizQp7pG%2FUcDEmmfTMh5RfkYR3v3k%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/mailman/listinfo.cgi/modules" shash="h1rNxKcZUvC4Fqs3vFPbiBG3z2WoURRAsRBoE9Qfhq01ag/e0tMiqSkSKQ/TBGQf2/T/xvPedbcwcw60gROemnXE6ACYN5G1fsg6AxbiUnixdb&#43;FxsgkVPahscsEM8Q6Kk8wOhIhr6/KIdFfkzqwt5KqdxmJiVzl6SkKjTpyMMY=" moz-do-not-send="true">
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;amp;sdata=3I0FUiH3dTqgwuEPP7VY%2BPiCSeuZatZeHLO8DMiHMho%3D&amp;amp;reserved=0</a></span><br>
<span>Link to this post: <a href="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%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936268461&amp;sdata=MEQMejzBthsyZ57dJxYxtuIWRDfwxbPd%2B77XT9nl62k%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/modules/2019/03/0240.php" shash="lFGcfAfdM0NcDVqsnAItj/C8bNbE7OWCvFhpPEjZa5GrXp3MqsAXTgOJ4BDSwrzSY1KSpTIHHJ2eHtiOm6O5vYV/tHdBti&#43;VOqAEw09GUJEnDSIdOuIbW0XJdvE6Hk/TxqxUX5UGJcSH5Xt7btqRpXfzDXqFcc78W/pYc2OVx3I=" moz-do-not-send="true">
https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0240.php&amp;amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;amp;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&amp;amp;reserved=0</a></span><br>
</div>
</blockquote>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Modules mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Modules@lists.isocpp.org">Modules@lists.isocpp.org</a>
Subscription: <a class="moz-txt-link-freetext" href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmailman%2Flistinfo.cgi%2Fmodules&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936278473&amp;sdata=rqvyUoaeHnctWY2KV8xkXcSO0PTHhzPush0K6g2c55E%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/mailman/listinfo.cgi/modules" shash="DCqqtzcRGrZYk3dNjf85iH1pHfzYlpNTJICaE7L4KMAp6OEK8zjwUl1Ip6XuT3uwXuX9hoCGPYDTFyH1yk7ZPvwUEs2/SpWQeFCJVNgVqUGwxdfLHNjM1qSeiFm0YSAtTNN2f7TenXkA8Q2Jt4r12tmg/S2j4mm5V&#43;41DDSqaEY=">http://lists.isocpp.org/mailman/listinfo.cgi/modules</a>
Link to this post: <a class="moz-txt-link-freetext" href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists.isocpp.org%2Fmodules%2F2019%2F03%2F0241.php&amp;data=02%7C01%7Cgdr%40microsoft.com%7C360f81598f0a459cc2f808d6a63dda91%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879181936278473&amp;sdata=ny1j%2B7gyw40Td2RvcWu1pec6CA1rF4bBxgsoG%2Fv7nfg%3D&amp;reserved=0" originalsrc="http://lists.isocpp.org/modules/2019/03/0241.php" shash="MPpeWCUtlR2zai4IWMSPVYgh5rHlRagMguNihZM9qF6AZMiuxwzF1EMV6avnAu5Awtr7Nr07ntjQ2IIHwlHgm7gfFOGp9AW0a7qXjo8K4efWWQzmVQNQ167&#43;NMnmtPFmzMpMnabjUTTreKATSQ/LJl0Kk9NG124maGj5wah5KPY=">http://lists.isocpp.org/modules/2019/03/0241.php</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
</blockquote>
</body>
</html>