<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<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]-->
</head>
<body lang="EN-US" link="#0563C1" vlink="#954F72">
<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&#8230;<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: https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules-install<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: https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/blob/master/header-units/external/CMakeLists.txt<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 &#8220;self-descriptive&#8221; 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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;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&#8217;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>
</body>
</html>