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;