<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">Invites were sent to the Tooling
      mailing list.  See
      <a class="moz-txt-link-freetext" href="http://www.open-std.org/pipermail/tooling/2019-March/000500.html">http://www.open-std.org/pipermail/tooling/2019-March/000500.html</a>. 
      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">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <div dir="ltr">Thanks! </div>
      <div dir="ltr"><br>
      </div>
      <div dir="ltr"> 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.  Actual notes below the
              break…<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            </div>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Minute Taker: Ben Craig<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal"><o:p> </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.  Let's work on it now and see
              when it is ready.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">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<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </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> </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> </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> </o:p></p>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Bryce: Just because the standard is out
              at C++20 doesn't mean that implementations will be
              available in C++20<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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++2a modes.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mathias: All the big compilers have
              early implementations<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </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> </o:p></p>
            <p class="MsoNormal">Ben Craig:  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> </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> </o:p></p>
            <p class="MsoNormal">Ben Boeckel: Need to determine where
              package managers should put module interface units.  That
              may be the extent of their involvement.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Tom: Don't forget Swig, static
              analyzers.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Bryce: Agreed.  Splitting build system
              vendors and tool vendors.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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?  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> </o:p></p>
            <p class="MsoNormal">JF: For Clang modules, we've been
              bridging between objective C and C++.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Mathias: Other languages may also
              produce modules to be consumed by C++<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">corentin:  I think I'd call them
              distribution too to avoid confusion with package<o:p></o:p></p>
            <p class="MsoNormal">Steve Downey:  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:  yes, thats linux-centric,
              but anything which deals with install prefixes cares<o:p></o:p></p>
            <p class="MsoNormal">Steve Downey:  BSD has a similar set of
              rules. Posix-ish<o:p></o:p></p>
            <p class="MsoNormal">ben.boeckel:  theyll get ports since
              bsd is C for the long term<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  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> </o:p></p>
            <p class="MsoNormal">Boris Kolpackov:  Here are some ideas
              on describing modular libraries in .pc (pkg-config) files:
              <a
href="https://build2.org/build2/doc/build2-build-system-manual.xhtml#cxx-modules-install"
                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> </o:p></p>
            <p class="MsoNormal">Boeckel: my first thoughts on cmake's
              iface: <a
href="https://gitlab.kitware.com/ben.boeckel/cxx-modules-sandbox/blob/master/header-units/external/CMakeLists.txt"
                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> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Tom: What do we need to do to enable
              adoption?  How can we adhere to what people do today?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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 &lt;foo&gt;?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Corentin: How do we avoid conflicts
              between module names?  How do we maintain ABI with
              modules?<o:p></o:p></p>
            <p class="MsoNormal">Bryce: Module ABI has multiple models
              of ownership.  We'll need to discuss it at some point.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  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> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  would generating the
              pkg-conf from the source be sufficiently self-descriptive
              for you?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </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> </o:p></p>
            <p class="MsoNormal">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<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  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> </o:p></p>
            <p class="MsoNormal">Boris Kolpackov:  yeah, looks pretty
              similar<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Michael Spencer:  Yeah<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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)<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  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> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Olga: Maybe group these into questions
              per stakeholder?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Bruno: How do we teach people to
              migrate to modules?  When do we suggest to use old
              #include, vs header units, vs modules.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Steve: What are the techniques for
              fixing your code so that it can be modular?  May be out of
              scope.  Cycle breaking for example.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Tom: How do people write headers that
              work for both C++20 and C++17?  While still being modular?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Corentin: How big should modules be? 
              What makes them too big, too small?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </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> </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> </o:p></p>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <p class="MsoNormal">ben.boeckel to Everyone:  yeah, but we
              can include "heres timings for project X using
              {tiny,large} modules for {new,old} build systems"<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">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.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Bryce: Specific use cases to address?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Tom: Existing build systems need to be
              able to consume modules, with minimal updates.  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> </o:p></p>
            <p class="MsoNormal">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 :)<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:  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> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Steve: Use case: Hello world with
              modules<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Olga: Just building module interfaces
              for tooling purposes.  Code completion.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mathias: Distributed builds (high
              bandwidth + high latency, and low bandwidth + 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> </o:p></p>
            <p class="MsoNormal">Mathias: What does an ideal one look
              like?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Tom: Static analysis tools, where
              source code is paramount.  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> </o:p></p>
            <p class="MsoNormal">Incremental Builds<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </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">   * Google mocks<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Things that generate code (out of
              scope?):<o:p></o:p></p>
            <p class="MsoNormal">   * protobuf<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">corentin: mixed build systems<o:p></o:p></p>
            <p class="MsoNormal">   Ex: CMake and QMake in the same
              build<o:p></o:p></p>
            <p class="MsoNormal">   More likely Cmake + lots of automake<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Steve: Bug reporting tools, like
              Creduce, delta<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Header only libraries<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Boost<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Boeckel: Provide #includes for
              backwards compat<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Corentin: Cuda, vulkan, openCL, SYCL<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">corentin:  tom : why not attributes
              rather than comments?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </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> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  I’m currently thinking
              GigE/same-switch LAN vs 10GigE/short-distance WAN<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">olgaark:  Internal dispributed builds
              (MS and others have it)<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  static analysis: viva64<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mark Zeren:  (if you build tensor flow,
              at least until it ports to swift...)<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Bruno Lopes:  GCCXML<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  superceded by castxml :)<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  Won’t anything using
              clang-tooling JustWork with modules with something like
              -frewrite-imports?<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">ben.boeckel:  swig reads and writes
              c++; protobuf writes it<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  I was thinking of it
              similarish to nim-lang which compile to C++ source among
              other targets<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">tom:  Mathias, maybe?  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> </o:p></p>
            <p class="MsoNormal">Mathias Stearn:  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> </o:p></p>
            <p class="MsoNormal">tom:  -frewrite-imports might consume
              an existing BMI.<o:p></o:p></p>
            <p class="MsoNormal"><o:p> </o:p></p>
            <p class="MsoNormal">Bruno Lopes:  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;amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;amp;sdata=3I0FUiH3dTqgwuEPP7VY%2BPiCSeuZatZeHLO8DMiHMho%3D&amp;amp;reserved=0"
              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;amp;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;amp;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&amp;amp;reserved=0"
              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="http://lists.isocpp.org/mailman/listinfo.cgi/modules">http://lists.isocpp.org/mailman/listinfo.cgi/modules</a>
Link to this post: <a class="moz-txt-link-freetext" href="http://lists.isocpp.org/modules/2019/03/0241.php">http://lists.isocpp.org/modules/2019/03/0241.php</a>
</pre>
    </blockquote>
    <p><br>
    </p>
  </body>
</html>