ISO C++ SG15 Tooling

Pre-Denver Modules Tooling Interactions Telecon

2019-08-02

Chairing: Bryce Adelstein Lelbach

Minute Taker: Ben Craig

Attendance:

   -

   Ben Craig
   -

   Ben Boeckel
   -

   Gabriel Dos Reis
   -

   Mathias Stearn
   -

   Boris Kolpackov
   -

   Bruno Lopes
   -

   Tom Honermann
   -

   Rene Rivera
   -

   Mark Zeren
   -

   JF Bastien


Today's Agenda:

   -

   Cologne summary
   -

      EWG review of P1688
      <http://wiki.edg.com/bin/view/Wg21cologne2019/P1688R0-EWG>
      -

      Friday SG15 session
      <http://wiki.edg.com/bin/view/Wg21cologne2019/SG15>
      -

   2019-09-21 Denver CppCon meeting
   -

   Post-Cologne mailing (2019-08-05)
   -

      P1687: Tooling Telecon Minutes (Bryce Adelstein Lelbach, Ben Craig)
      -

      P1689: Dependency Information Format (Ben Boeckel)
      -

      Generalized Module Mapper (Boris Kolpackov)
      -

   D1383R0: Modules User-Facing Lexicon and File Extensions
   <https://docs.google.com/document/d/1SnvmlhUMTODRTkbw_ie-anT8heta52qlkA28CBQOpJw/edit?usp=sharing>
   -

      CMI/BMI bikeshedding
      -

      File extensions


Polls:

POLL: Which names can you tolerate? (Vote as many times as you like)

Binary Module Interface (BMI) 10

Built Module Interface (BMI) 8

Compiled Module Interface (CMI) 6

PreCompiled Module (PCM) 4

Module Interface Metadata (MIM) 3

Module Interface Cache (MIC) 4

Importable Module Artifact (IMA) 9

POLL: Which name do you prefer?

Binary Module Interface (BMI) 5

Built Module Interface (BMI) 5

Importable Module Artifact (IMA) 1

CONSENSUS: We like the acronym BMI.

Action Items:

   -

   Publish P1687R1 with minutes from the 2019-06-21 and 2019-08-02 telecon
   (Bryce Adelstein Lelbach)
   -

   Publish new paper with details of the 2019-09-21 Denver CppCon meeting
   (Bryce Adelstein Lelbach)
   -

   Share D1833R0 with everybody (Bryce Adelstein Lelbach)


---------- Forwarded message ---------
From: Ben Craig <ben.craig_at_[hidden]>
Date: Fri, Aug 2, 2019 at 10:02 AM
Subject: sg15 8/2
To: BRYCELELBACH_at_[hidden] <BRYCELELBACH_at_[hidden]>, Bryce Adelstein
Lelbach aka wash <blelbach_at_[hidden]>


Bryce Lelbach

Ben Craig

Mathias Stearn

Ben Boeckel

Rene Rivera

Gabriel Dos Reis

Boris Kolpackov

Tom Honermann

Bruno Lopes

Mark Zeren

JF Bastien





Bryce: Denver CppCon meeting. Consensus is Saturdat after CppCon 2019. Sep
21.

Will try to have a telecon presence. Will set up a pseudo mailing deadline.

Limiting to the modules ecosystem TR.



Boeckel: Planning on getting P1689 into the post meeting mailing?



Boris: planning on having a paper for generic module mapper



Bryce: Modules lexicon paper. Want to have shared terminology in
preparation for CppCon



Craig: I just want consistency



Tom: I do like PCM because it's sort of like precompiled headers



Gabby: Because of that, I would go in the opposite direction. Like CMI,
since it doesn't need to be stored in a binary form.



Mathias: How do we name the act of generating the BMI / CMI? How do we need
to name the act of making an object file?



Bryce: Some impls have distince steps for making obj and CMI, some impls
have one step.

Boeckel: Fortran uses two step



General disagreement on which is more efficient.



Mathias: Been thinking of obj production as "compiling" and CMI production
as extracting.

Gabby: Maybe "metadata" instead (module interface metadata?)

Boris: What is meta about it? what is the data?

Gabby: Prior art, it's meta in the sense that it isn't the .obj

Boeckel: Module interface cache? Interfaces the transient nature

Gabby: Would need to distinguish the term in caching systems.

Boeckel: Importable Module Artifact?

Boris: We should keep in mind that there are a lot of existing documents
that use BMI.

If we don't have a significantly better term, we should prefer the status
quo.

If we want to be precise, then this doesn't always apply to module, but
also to headers.



Bruno: I like binary because it could mean metadata or machine code, where
compiled gives impression of machine code.



Informative poll (vote for all you can tolerate:

Binary Module Interface (BMI) 10

Built Module Interface (BMI) 8

Compiled Module Interface (CMI) 6

PreCompiled Module (PCM) 4

Module Interface Metadata (MIM) 3

Module Interface Cache (MIC) 4

Importable Module Artifact (IMA) 9



Gaby: We'll need to use this in the context of builds. When we talk about
headers / modules, the word module might confuse things



Poll which do you prefer?

Binary Module Interface (BMI) 5

Built Module Interface (BMI) 5

Importable Module Artiface (IMA) 1



BMI abbreviation seems to win.



>From Rene Rivera to Everyone: 11:27 AM

Since this might end up as a file extension we might want to keep in mind
this:

IMA Mirage vector graphics EGO - Chart - Autumn

IMA Disk image WinImage



>From ben.boeckel to Everyone: 11:28 AM

why does it have to stand for anything? just call it BMI



Bryce: Current status quo is that interface units have a different
extension?

Gabby: Only the interface has a different extension



Mathias:

What are importable implementation units: Named partitions that are not
exported

Seem to behave more like interface units, because you need a BMI for them

For anything that is importable. Even implementation units can be imported.

Maybe don't do it at all?



Gaby:

MSVC has distinct extensions to make other tools easier.

Can't change Visual Studio to not care about extension.



Mathias:

Not proposing that it doesn't have an extension, just proposing that it
doesn't have a different extension



Gaby:

Interfaces get treated a bit different from headers and implementation
files.

Treating an interface file as a header file isn't adequate semantically.



Tom:

This is for driving build systems?



Gaby: This is for driving the editor and the compiler. Without the
extension, you need more compiler switches to disambiguate.



>From Boris to Everyone: 11:35 AM

@Bryce: I don't believe GCC uses .cppm, I think you meant Clang?

AFAIK, GCC/Nathan does not suggest a separate extension.



Bryce: Overloading what .cpp means too much seems unnecessary



Gaby: Didn't do this lightly in 2015



Different extension seems useful. Suggesting .cmi



Craig: Cost to existing editors that don't recognize the extension

Mark: Cost goes both ways, in that editors and tools can't specialize



Mathias: Reduced scanning on non-importable units.

Boeckel: You have to scan anything that could import as well.

Mathias: That would be my argument that you keep all the extensions the
same,

since all need to be scanned anyway



Tom: Need to support build systems without a scan step. Whole world isn't
going to transition to cmake.



Boeckel: A two or three level recursive make may be able to pull off
scanning. I want to make a paper that says how our generated makefiles
work.



Bryce: On produced files, hopefully the implementations will coallesce on
an extension.

MSVC uses .ifc.

Want to avoid .o or .obj mismatch, but this isn't as high of a priority.

GCC doesn't seem to support telling it which extension to use.



Gaby: Implementation unit, I see .cpp and .mxx. GCC allows .cc and .cxx

Bryce: Not currently exhaustive. .cpp is a placeholder for all the
existing extensions.



Boeckel: gcc uses gcm, gcmu, or gcms depending on the type.



Boris: I think Nathan changed that.



Boeckel: Default module mapper uses CWD and makes up names, if you give it
a module map, it uses that.



>From Boris to Everyone: 11:45 AM

@Bryce: with GCC you can write the BMI to any file (any name/extension,
etc) using the module mapper.



Bikeshedding over "Dependency Metadata" / "Dependency Information"



Mathias: Rather not use implicit vs. explicit for this distinction.
Explicit sounds like users are managing it.

Maybe compiler managed, build system managed, user managed



Some discussion over merging Mathias's categories



Gaby: Please don't use the terms implicit and explicit terms for "Implicit
Modules" and "Explicit Modules"



Bryce: This should probably be considered anti-terminology



Craig: Need different words for textual #include <foo>, header unit
#include <foo>, and module import foo;

-- 
Bryce Adelstein Lelbach aka wash
CUDA Core C++ Libraries Lead @ NVIDIA
ISO C++ Library Evolution Incubator Chair
ISO C++ Tooling Chair
CppCon and C++Now Program Chair
CUDA Convert and Reformed AVX Junkie
Sleep is for the weak
--