<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 <<a
href="mailto:ben.craig@ni.com" moz-do-not-send="true">ben.craig@ni.com</a>>
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 <foo>?<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;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3I0FUiH3dTqgwuEPP7VY%2BPiCSeuZatZeHLO8DMiHMho%3D&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;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3I0FUiH3dTqgwuEPP7VY%2BPiCSeuZatZeHLO8DMiHMho%3D&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%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&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;data=02%7C01%7Cgdr%40microsoft.com%7C5dec9483baef4764a94e08d6a62363ca%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636879068266145599&amp;sdata=3W%2FSwGGme1Rmus9mrCrQXGgiaZuQvryhpcqpb7pE49I%3D&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>