<!doctype html><html lang="en">
 <head>
  <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  <meta content="width=device-width, initial-scale=1, shrink-to-fit=no" name="viewport">
  <title>P1687R1: Summary of the Tooling Study Group’s Modules Ecosystem Technical Report Telecons</title>
<style data-fill-with="stylesheet">/******************************************************************************
 *                   Style sheet for the W3C specifications                   *
 *
 * Special classes handled by this style sheet include:
 *
 * Indices
 *   - .toc for the Table of Contents (<ol class="toc">)
 *     + <span class="secno"> for the section numbers
 *   - #toc for the Table of Contents (<nav id="toc">)
 *   - ul.index for Indices (<a href="#ref">term</a><span>, in §N.M</span>)
 *   - table.index for Index Tables (e.g. for properties or elements)
 *
 * Structural Markup
 *   - table.data for general data tables
 *     -> use 'scope' attribute, <colgroup>, <thead>, and <tbody> for best results !
 *     -> use <table class='complex data'> for extra-complex tables
 *     -> use <td class='long'> for paragraph-length cell content
 *     -> use <td class='pre'> when manual line breaks/indentation would help readability
 *   - dl.switch for switch statements
 *   - ol.algorithm for algorithms (helps to visualize nesting)
 *   - .figure and .caption (HTML4) and figure and figcaption (HTML5)
 *     -> .sidefigure for right-floated figures
 *   - ins/del
 *
 * Code
 *   - pre and code
 *
 * Special Sections
 *   - .note       for informative notes             (div, p, span, aside, details)
 *   - .example    for informative examples          (div, p, pre, span)
 *   - .issue      for issues                        (div, p, span)
 *   - .assertion  for assertions                    (div, p, span)
 *   - .advisement for loud normative statements     (div, p, strong)
 *   - .annoying-warning for spec obsoletion notices (div, aside, details)
 *
 * Definition Boxes
 *   - pre.def   for WebIDL definitions
 *   - table.def for tables that define other entities (e.g. CSS properties)
 *   - dl.def    for definition lists that define other entitles (e.g. HTML elements)
 *
 * Numbering
 *   - .secno for section numbers in .toc and headings (<span class='secno'>3.2</span>)
 *   - .marker for source-inserted example/figure/issue numbers (<span class='marker'>Issue 4</span>)
 *   - ::before styled for CSS-generated issue/example/figure numbers:
 *     -> Documents wishing to use this only need to add
 *        figcaption::before,
 *        .caption::before { content: "Figure "  counter(figure) " ";  }
 *        .example::before { content: "Example " counter(example) " "; }
 *        .issue::before   { content: "Issue "   counter(issue) " ";   }
 *
 * Header Stuff (ignore, just don't conflict with these classes)
 *   - .head for the header
 *   - .copyright for the copyright
 *
 * Miscellaneous
 *   - .overlarge for things that should be as wide as possible, even if
 *     that overflows the body text area. This can be used on an item or
 *     on its container, depending on the effect desired.
 *     Note that this styling basically doesn't help at all when printing,
 *     since A4 paper isn't much wider than the max-width here.
 *     It's better to design things to fit into a narrower measure if possible.
 *   - js-added ToC jump links (see fixup.js)
 *
 ******************************************************************************/

/******************************************************************************/
/*                                   Body                                     */
/******************************************************************************/

	body {
		counter-reset: example figure issue;

		/* Layout */
		max-width: 50em;               /* limit line length to 50em for readability   */
		margin: 0 auto;                /* center text within page                     */
		padding: 1.6em 1.5em 2em 50px; /* assume 16px font size for downlevel clients */
		padding: 1.6em 1.5em 2em calc(26px + 1.5em); /* leave space for status flag     */

		/* Typography */
		line-height: 1.5;
		font-family: sans-serif;
		widows: 2;
		orphans: 2;
		word-wrap: break-word;
		overflow-wrap: break-word;
		hyphens: auto;

		/* Colors */
		color: black;
		background: white top left fixed no-repeat;
		background-size: 25px auto;
	}


/******************************************************************************/
/*                         Front Matter & Navigation                          */
/******************************************************************************/

/** Header ********************************************************************/

	div.head { margin-bottom: 1em }
	div.head hr { border-style: solid; }

	div.head h1 {
		font-weight: bold;
		margin: 0 0 .1em;
		font-size: 220%;
	}

	div.head h2 { margin-bottom: 1.5em;}

/** W3C Logo ******************************************************************/

	.head .logo {
		float: right;
		margin: 0.4rem 0 0.2rem .4rem;
	}

	.head img[src*="logos/W3C"] {
		display: block;
		border: solid #1a5e9a;
		border-width: .65rem .7rem .6rem;
		border-radius: .4rem;
		background: #1a5e9a;
		color: white;
		font-weight: bold;
	}

	.head a:hover > img[src*="logos/W3C"],
	.head a:focus > img[src*="logos/W3C"] {
		opacity: .8;
	}

	.head a:active > img[src*="logos/W3C"] {
		background: #c00;
		border-color: #c00;
	}

	/* see also additional rules in Link Styling section */

/** Copyright *****************************************************************/

	p.copyright,
	p.copyright small { font-size: small }

/** Back to Top / ToC Toggle **************************************************/

	@media print {
		#toc-nav {
			display: none;
		}
	}
	@media not print {
		#toc-nav {
			position: fixed;
			z-index: 2;
			bottom: 0; left: 0;
			margin: 0;
			min-width: 1.33em;
			border-top-right-radius: 2rem;
			box-shadow: 0 0 2px;
			font-size: 1.5em;
			color: black;
		}
		#toc-nav > a {
			display: block;
			white-space: nowrap;

			height: 1.33em;
			padding: .1em 0.3em;
			margin: 0;

			background: white;
			box-shadow: 0 0 2px;
			border: none;
			border-top-right-radius: 1.33em;
			background: white;
		}
		#toc-nav > #toc-jump {
			padding-bottom: 2em;
			margin-bottom: -1.9em;
		}

		#toc-nav > a:hover,
		#toc-nav > a:focus {
			background: #f8f8f8;
		}
		#toc-nav > a:not(:hover):not(:focus) {
			color: #707070;
		}

		/* statusbar gets in the way on keyboard focus; remove once browsers fix */
		#toc-nav > a[href="#toc"]:not(:hover):focus:last-child {
			padding-bottom: 1.5rem;
		}

		#toc-nav:not(:hover) > a:not(:focus) > span + span {
			/* Ideally this uses :focus-within on #toc-nav */
			display: none;
		}
		#toc-nav > a > span + span {
			padding-right: 0.2em;
		}

		#toc-toggle-inline {
			vertical-align: 0.05em;
			font-size: 80%;
			color: gray;
			color: hsla(203,20%,40%,.7);
			border-style: none;
			background: transparent;
			position: relative;
		}
		#toc-toggle-inline:hover:not(:active),
		#toc-toggle-inline:focus:not(:active) {
			text-shadow: 1px 1px silver;
			top: -1px;
			left: -1px;
		}

		#toc-nav :active {
			color: #C00;
		}
	}

/** ToC Sidebar ***************************************************************/

	/* Floating sidebar */
	@media screen {
		body.toc-sidebar #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			max-width: 80%;
			max-width: calc(100% - 2em - 26px);
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body.toc-sidebar #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}
		body.toc-sidebar #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	/* Hide main scroller when only the ToC is visible anyway */
	@media screen and (max-width: 28em) {
		body.toc-sidebar {
			overflow: hidden;
		}
	}

	/* Sidebar with its own space */
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) #toc {
			position: fixed;
			top: 0; bottom: 0;
			left: 0;
			width: 23.5em;
			overflow: auto;
			padding: 0 1em;
			padding-left: 42px;
			padding-left: calc(1em + 26px);
			background: inherit;
			background-color: #f7f8f9;
			z-index: 1;
			box-shadow: -.1em 0 .25em rgba(0,0,0,.1) inset;
		}
		body:not(.toc-inline) #toc h2 {
			margin-top: .8rem;
			font-variant: small-caps;
			font-variant: all-small-caps;
			text-transform: lowercase;
			font-weight: bold;
			color: gray;
			color: hsla(203,20%,40%,.7);
		}

		body:not(.toc-inline) {
			padding-left: 29em;
		}
		/* See also Overflow section at the bottom */

		body:not(.toc-inline) #toc-jump:not(:focus) {
			width: 0;
			height: 0;
			padding: 0;
			position: absolute;
			overflow: hidden;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) {
			margin: 0 4em;
		}
	}

/******************************************************************************/
/*                                Sectioning                                  */
/******************************************************************************/

/** Headings ******************************************************************/

	h1, h2, h3, h4, h5, h6, dt {
		page-break-after: avoid;
		page-break-inside: avoid;
		font: 100% sans-serif;   /* Reset all font styling to clear out UA styles */
		font-family: inherit;    /* Inherit the font family. */
		line-height: 1.2;        /* Keep wrapped headings compact */
		hyphens: manual;         /* Hyphenated headings look weird */
	}

	h2, h3, h4, h5, h6 {
		margin-top: 3rem;
	}

	h1, h2, h3 {
		color: #005A9C;
		background: transparent;
	}

	h1 { font-size: 170%; }
	h2 { font-size: 140%; }
	h3 { font-size: 120%; }
	h4 { font-weight: bold; }
	h5 { font-style: italic; }
	h6 { font-variant: small-caps; }
	dt { font-weight: bold; }

/** Subheadings ***************************************************************/

	h1 + h2,
	#subtitle {
		/* #subtitle is a subtitle in an H2 under the H1 */
		margin-top: 0;
	}
	h2 + h3,
	h3 + h4,
	h4 + h5,
	h5 + h6 {
		margin-top: 1.2em; /* = 1 x line-height */
	}

/** Section divider ***********************************************************/

	:not(.head) > hr {
		font-size: 1.5em;
		text-align: center;
		margin: 1em auto;
		height: auto;
		border: transparent solid 0;
		background: transparent;
	}
	:not(.head) > hr::before {
		content: "\2727\2003\2003\2727\2003\2003\2727";
	}

/******************************************************************************/
/*                            Paragraphs and Lists                            */
/******************************************************************************/

	p {
		margin: 1em 0;
	}

	dd > p:first-child,
	li > p:first-child {
		margin-top: 0;
	}

	ul, ol {
		margin-left: 0;
		padding-left: 2em;
	}

	li {
		margin: 0.25em 0 0.5em;
		padding: 0;
	}

	dl dd {
		margin: 0 0 .5em 2em;
	}

	.head dd + dd { /* compact for header */
		margin-top: -.5em;
	}

	/* Style for algorithms */
	ol.algorithm ol:not(.algorithm),
	.algorithm > ol ol:not(.algorithm) {
	 border-left: 0.5em solid #DEF;
	}

	/* Put nice boxes around each algorithm. */
	[data-algorithm]:not(.heading) {
	  padding: .5em;
	  border: thin solid #ddd; border-radius: .5em;
	  margin: .5em calc(-0.5em - 1px);
	}
	[data-algorithm]:not(.heading) > :first-child {
	  margin-top: 0;
	}
	[data-algorithm]:not(.heading) > :last-child {
	  margin-bottom: 0;
	}

	/* Style for switch/case <dl>s */
	dl.switch > dd > ol.only,
	dl.switch > dd > .only > ol {
	 margin-left: 0;
	}
	dl.switch > dd > ol.algorithm,
	dl.switch > dd > .algorithm > ol {
	 margin-left: -2em;
	}
	dl.switch {
	 padding-left: 2em;
	}
	dl.switch > dt {
	 text-indent: -1.5em;
	 margin-top: 1em;
	}
	dl.switch > dt + dt {
	 margin-top: 0;
	}
	dl.switch > dt::before {
	 content: '\21AA';
	 padding: 0 0.5em 0 0;
	 display: inline-block;
	 width: 1em;
	 text-align: right;
	 line-height: 0.5em;
	}

/** Terminology Markup ********************************************************/


/******************************************************************************/
/*                                 Inline Markup                              */
/******************************************************************************/

/** Terminology Markup ********************************************************/
	dfn   { /* Defining instance */
		font-weight: bolder;
	}
	a > i { /* Instance of term */
		font-style: normal;
	}
	dt dfn code, code.idl {
		font-size: medium;
	}
	dfn var {
		font-style: normal;
	}

/** Change Marking ************************************************************/

	del { color: red;  text-decoration: line-through; }
	ins { color: #080; text-decoration: underline;    }

/** Miscellaneous improvements to inline formatting ***************************/

	sup {
		vertical-align: super;
		font-size: 80%
	}

/******************************************************************************/
/*                                    Code                                    */
/******************************************************************************/

/** General monospace/pre rules ***********************************************/

	pre, code, samp {
		font-family: Menlo, Consolas, "DejaVu Sans Mono", Monaco, monospace;
		font-size: .9em;
		page-break-inside: avoid;
		hyphens: none;
		text-transform: none;
	}
	pre code,
	code code {
		font-size: 100%;
	}

	pre {
		margin-top: 1em;
		margin-bottom: 1em;
		overflow: auto;
	}

/** Inline Code fragments *****************************************************/

  /* Do something nice. */

/******************************************************************************/
/*                                    Links                                   */
/******************************************************************************/

/** General Hyperlinks ********************************************************/

	/* We hyperlink a lot, so make it less intrusive */
	a[href] {
		color: #034575;
		text-decoration: none;
		border-bottom: 1px solid #707070;
		/* Need a bit of extending for it to look okay */
		padding: 0 1px 0;
		margin: 0 -1px 0;
	}
	a:visited {
		border-bottom-color: #BBB;
	}

	/* Use distinguishing colors when user is interacting with the link */
	a[href]:focus,
	a[href]:hover {
		background: #f8f8f8;
		background: rgba(75%, 75%, 75%, .25);
		border-bottom-width: 3px;
		margin-bottom: -2px;
	}
	a[href]:active {
		color: #C00;
		border-color: #C00;
	}

	/* Backout above styling for W3C logo */
	.head .logo,
	.head .logo a {
		border: none;
		text-decoration: none;
		background: transparent;
	}

/******************************************************************************/
/*                                    Images                                  */
/******************************************************************************/

	img {
		border-style: none;
	}

	/* For autogen numbers, add
	   .caption::before, figcaption::before { content: "Figure " counter(figure) ". "; }
	*/

	figure, .figure, .sidefigure {
		page-break-inside: avoid;
		text-align: center;
		margin: 2.5em 0;
	}
	.figure img,    .sidefigure img,    figure img,
	.figure object, .sidefigure object, figure object {
		max-width: 100%;
		margin: auto;
	}
	.figure pre, .sidefigure pre, figure pre {
		text-align: left;
		display: table;
		margin: 1em auto;
	}
	.figure table, figure table {
		margin: auto;
	}
	@media screen and (min-width: 20em) {
		.sidefigure {
			float: right;
			width: 50%;
			margin: 0 0 0.5em 0.5em
		}
	}
	.caption, figcaption, caption {
		font-style: italic;
		font-size: 90%;
	}
	.caption::before, figcaption::before, figcaption > .marker {
		font-weight: bold;
	}
	.caption, figcaption {
		counter-increment: figure;
	}

	/* DL list is indented 2em, but figure inside it is not */
	dd > .figure, dd > figure { margin-left: -2em }

/******************************************************************************/
/*                             Colored Boxes                                  */
/******************************************************************************/

	.issue, .note, .example, .assertion, .advisement, blockquote {
		padding: .5em;
		border: .5em;
		border-left-style: solid;
		page-break-inside: avoid;
	}
	span.issue, span.note {
		padding: .1em .5em .15em;
		border-right-style: solid;
	}

	.issue,
	.note,
	.example,
	.advisement,
	.assertion,
	blockquote {
		margin: 1em auto;
	}
	.note  > p:first-child,
	.issue > p:first-child,
	blockquote > :first-child {
		margin-top: 0;
	}
	blockquote > :last-child {
		margin-bottom: 0;
	}

/** Blockquotes ***************************************************************/

	blockquote {
		border-color: silver;
	}

/** Open issue ****************************************************************/

	.issue {
		border-color: #E05252;
		background: #FBE9E9;
		counter-increment: issue;
		overflow: auto;
	}
	.issue::before, .issue > .marker {
		text-transform: uppercase;
		color: #AE1E1E;
		padding-right: 1em;
		text-transform: uppercase;
	}
	/* Add .issue::before { content: "Issue " counter(issue) " "; } for autogen numbers,
	   or use class="marker" to mark up the issue number in source. */

/** Example *******************************************************************/

	.example {
		border-color: #E0CB52;
		background: #FCFAEE;
		counter-increment: example;
		overflow: auto;
		clear: both;
	}
	.example::before, .example > .marker {
		text-transform: uppercase;
		color: #827017;
		min-width: 7.5em;
		display: block;
	}
	/* Add .example::before { content: "Example " counter(example) " "; } for autogen numbers,
	   or use class="marker" to mark up the example number in source. */

/** Non-normative Note ********************************************************/

	.note {
		border-color: #52E052;
		background: #E9FBE9;
		overflow: auto;
	}

	.note::before, .note > .marker,
	details.note > summary::before,
	details.note > summary > .marker {
		text-transform: uppercase;
		display: block;
		color: hsl(120, 70%, 30%);
	}
	/* Add .note::before { content: "Note"; } for autogen label,
	   or use class="marker" to mark up the label in source. */

	details.note > summary {
		display: block;
		color: hsl(120, 70%, 30%);
	}
	details.note[open] > summary {
		border-bottom: 1px silver solid;
	}

/** Assertion Box *************************************************************/
	/*  for assertions in algorithms */

	.assertion {
		border-color: #AAA;
		background: #EEE;
	}

/** Advisement Box ************************************************************/
	/*  for attention-grabbing normative statements */

	.advisement {
		border-color: orange;
		border-style: none solid;
		background: #FFEECC;
	}
	strong.advisement {
		display: block;
		text-align: center;
	}
	.advisement > .marker {
		color: #B35F00;
	}

/** Spec Obsoletion Notice ****************************************************/
	/* obnoxious obsoletion notice for older/abandoned specs. */

	details {
		display: block;
	}
	summary {
		font-weight: bolder;
	}

	.annoying-warning:not(details),
	details.annoying-warning:not([open]) > summary,
	details.annoying-warning[open] {
		background: #fdd;
		color: red;
		font-weight: bold;
		padding: .75em 1em;
		border: thick red;
		border-style: solid;
		border-radius: 1em;
	}
	.annoying-warning :last-child {
		margin-bottom: 0;
	}

@media not print {
	details.annoying-warning[open] {
		position: fixed;
		left: 1em;
		right: 1em;
		bottom: 1em;
		z-index: 1000;
	}
}

	details.annoying-warning:not([open]) > summary {
		text-align: center;
	}

/** Entity Definition Boxes ***************************************************/

	.def {
		padding: .5em 1em;
		background: #DEF;
		margin: 1.2em 0;
		border-left: 0.5em solid #8CCBF2;
	}

/******************************************************************************/
/*                                    Tables                                  */
/******************************************************************************/

	th, td {
		text-align: left;
		text-align: start;
	}

/** Property/Descriptor Definition Tables *************************************/

	table.def {
		/* inherits .def box styling, see above */
		width: 100%;
		border-spacing: 0;
	}

	table.def td,
	table.def th {
		padding: 0.5em;
		vertical-align: baseline;
		border-bottom: 1px solid #bbd7e9;
	}

	table.def > tbody > tr:last-child th,
	table.def > tbody > tr:last-child td {
		border-bottom: 0;
	}

	table.def th {
		font-style: italic;
		font-weight: normal;
		padding-left: 1em;
		width: 3em;
	}

	/* For when values are extra-complex and need formatting for readability */
	table td.pre {
		white-space: pre-wrap;
	}

	/* A footnote at the bottom of a def table */
	table.def           td.footnote {
		padding-top: 0.6em;
	}
	table.def           td.footnote::before {
		content: " ";
		display: block;
		height: 0.6em;
		width: 4em;
		border-top: thin solid;
	}

/** Data tables (and properly marked-up index tables) *************************/
	/*
		 <table class="data"> highlights structural relationships in a table
		 when correct markup is used (e.g. thead/tbody, th vs. td, scope attribute)

		 Use class="complex data" for particularly complicated tables --
		 (This will draw more lines: busier, but clearer.)

		 Use class="long" on table cells with paragraph-like contents
		 (This will adjust text alignment accordingly.)
		 Alternately use class="longlastcol" on tables, to have the last column assume "long".
	*/

	table {
		word-wrap: normal;
		overflow-wrap: normal;
		hyphens: manual;
	}

	table.data,
	table.index {
		margin: 1em auto;
		border-collapse: collapse;
		border: hidden;
		width: 100%;
	}
	table.data caption,
	table.index caption {
		max-width: 50em;
		margin: 0 auto 1em;
	}

	table.data td,  table.data th,
	table.index td, table.index th {
		padding: 0.5em 1em;
		border-width: 1px;
		border-color: silver;
		border-top-style: solid;
	}

	table.data thead td:empty {
		padding: 0;
		border: 0;
	}

	table.data  thead,
	table.index thead,
	table.data  tbody,
	table.index tbody {
		border-bottom: 2px solid;
	}

	table.data colgroup,
	table.index colgroup {
		border-left: 2px solid;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		border-right: 2px solid;
		border-top: 1px solid silver;
		padding-right: 1em;
	}

	table.data th[colspan],
	table.data td[colspan] {
		text-align: center;
	}

	table.complex.data th,
	table.complex.data td {
		border: 1px solid silver;
		text-align: center;
	}

	table.data.longlastcol td:last-child,
	table.data td.long {
	 vertical-align: baseline;
	 text-align: left;
	}

	table.data img {
		vertical-align: middle;
	}


/*
Alternate table alignment rules

	table.data,
	table.index {
		text-align: center;
	}

	table.data  thead th[scope="row"],
	table.index thead th[scope="row"] {
		text-align: right;
	}

	table.data  tbody th:first-child,
	table.index tbody th:first-child  {
		text-align: right;
	}

Possible extra rowspan handling

	table.data  tbody th[rowspan]:not([rowspan='1']),
	table.index tbody th[rowspan]:not([rowspan='1']),
	table.data  tbody td[rowspan]:not([rowspan='1']),
	table.index tbody td[rowspan]:not([rowspan='1']) {
		border-left: 1px solid silver;
	}

	table.data  tbody th[rowspan]:first-child,
	table.index tbody th[rowspan]:first-child,
	table.data  tbody td[rowspan]:first-child,
	table.index tbody td[rowspan]:first-child{
		border-left: 0;
		border-right: 1px solid silver;
	}
*/

/******************************************************************************/
/*                                  Indices                                   */
/******************************************************************************/


/** Table of Contents *********************************************************/

	.toc a {
		/* More spacing; use padding to make it part of the click target. */
		padding-top: 0.1rem;
		/* Larger, more consistently-sized click target */
		display: block;
		/* Reverse color scheme */
		color: black;
		border-color: #3980B5;
		border-bottom-width: 3px !important;
		margin-bottom: 0px !important;
	}
	.toc a:visited {
		border-color: #054572;
	}
	.toc a:not(:focus):not(:hover) {
		/* Allow colors to cascade through from link styling */
		border-bottom-color: transparent;
	}

	.toc, .toc ol, .toc ul, .toc li {
		list-style: none; /* Numbers must be inlined into source */
		/* because generated content isn't search/selectable and markers can't do multilevel yet */
		margin:  0;
		padding: 0;
		line-height: 1.1rem; /* consistent spacing */
	}

	/* ToC not indented until third level, but font style & margins show hierarchy */
	.toc > li             { font-weight: bold;   }
	.toc > li li          { font-weight: normal; }
	.toc > li li li       { font-size:   95%;    }
	.toc > li li li li    { font-size:   90%;    }
	.toc > li li li li .secno { font-size: 85%; }
	.toc > li li li li li { font-size:   85%;    }
	.toc > li li li li li .secno { font-size: 100%; }

	/* @supports not (display:grid) { */
		.toc > li             { margin: 1.5rem 0;    }
		.toc > li li          { margin: 0.3rem 0;    }
		.toc > li li li       { margin-left: 2rem;   }

		/* Section numbers in a column of their own */
		.toc .secno {
			float: left;
			width: 4rem;
			white-space: nowrap;
		}

		.toc li {
			clear: both;
		}

		:not(li) > .toc              { margin-left:  5rem; }
		.toc .secno                  { margin-left: -5rem; }
		.toc > li li li .secno       { margin-left: -7rem; }
		.toc > li li li li .secno    { margin-left: -9rem; }
		.toc > li li li li li .secno { margin-left: -11rem; }

		/* Tighten up indentation in narrow ToCs */
		@media (max-width: 30em) {
			:not(li) > .toc              { margin-left:  4rem; }
			.toc .secno                  { margin-left: -4rem; }
			.toc > li li li              { margin-left:  1rem; }
			.toc > li li li .secno       { margin-left: -5rem; }
			.toc > li li li li .secno    { margin-left: -6rem; }
			.toc > li li li li li .secno { margin-left: -7rem; }
		}
	/* } */

	@supports (display:grid) {
		/* Use #toc over .toc to override non-@supports rules. */
		#toc {
			display: grid;
			align-content: start;
			grid-template-columns: auto 1fr;
			grid-column-gap: 1rem;
			column-gap: 1rem;
			grid-row-gap: .6rem;
			row-gap: .6rem;
		}
		#toc h2 {
			grid-column: 1 / -1;
			margin-bottom: 0;
		}
		#toc ol,
		#toc li,
		#toc a {
			display: contents;
			/* Switch <a> to subgrid when supported */
		}
		#toc span {
			margin: 0;
		}
		#toc > .toc > li > a > span {
			/* The spans of the top-level list,
			   comprising the first items of each top-level section. */
			margin-top: 1.1rem;
		}
		#toc#toc .secno { /* Ugh, need more specificity to override base.css */
			grid-column: 1;
			width: auto;
			margin-left: 0;
		}
		#toc .content {
			grid-column: 2;
			width: auto;
			margin-right: 1rem;
		}
		#toc .content:hover {
			background: rgba(75%, 75%, 75%, .25);
			border-bottom: 3px solid #054572;
			margin-bottom: -3px;
		}
		#toc li li li .content {
			margin-left: 1rem;
		}
		#toc li li li li .content {
			margin-left: 2rem;
		}
	}


/** Index *********************************************************************/

	/* Index Lists: Layout */
	ul.index       { margin-left: 0; columns: 15em; text-indent: 1em hanging; }
	ul.index li    { margin-left: 0; list-style: none; break-inside: avoid; }
	ul.index li li { margin-left: 1em }
	ul.index dl    { margin-top: 0; }
	ul.index dt    { margin: .2em 0 .2em 20px;}
	ul.index dd    { margin: .2em 0 .2em 40px;}
	/* Index Lists: Typography */
	ul.index ul,
	ul.index dl { font-size: smaller; }
	@media not print {
		ul.index li span {
			white-space: nowrap;
			color: transparent; }
		ul.index li a:hover + span,
		ul.index li a:focus + span {
			color: #707070;
		}
	}

/** Index Tables *****************************************************/
	/* See also the data table styling section, which this effectively subclasses */

	table.index {
		font-size: small;
		border-collapse: collapse;
		border-spacing: 0;
		text-align: left;
		margin: 1em 0;
	}

	table.index td,
	table.index th {
		padding: 0.4em;
	}

	table.index tr:hover td:not([rowspan]),
	table.index tr:hover th:not([rowspan]) {
		background: #f7f8f9;
	}

	/* The link in the first column in the property table (formerly a TD) */
	table.index th:first-child a {
		font-weight: bold;
	}

/******************************************************************************/
/*                                    Print                                   */
/******************************************************************************/

	@media print {
		/* Pages have their own margins. */
		html {
			margin: 0;
		}
		/* Serif for print. */
		body {
			font-family: serif;
		}
	}
	@page {
		margin: 1.5cm 1.1cm;
	}

/******************************************************************************/
/*                                    Legacy                                  */
/******************************************************************************/

	/* This rule is inherited from past style sheets. No idea what it's for. */
	.hide { display: none }



/******************************************************************************/
/*                             Overflow Control                               */
/******************************************************************************/

	.figure .caption, .sidefigure .caption, figcaption {
		/* in case figure is overlarge, limit caption to 50em */
		max-width: 50rem;
		margin-left: auto;
		margin-right: auto;
	}
	.overlarge > table {
		/* limit preferred width of table */
		max-width: 50em;
		margin-left: auto;
		margin-right: auto;
	}

	@media (min-width: 55em) {
		.overlarge {
			margin-left: calc(13px + 26.5rem - 50vw);
			margin-right: calc(13px + 26.5rem - 50vw);
			max-width: none;
		}
	}
	@media screen and (min-width: 78em) {
		body:not(.toc-inline) .overlarge {
			/* 30.5em body padding 50em content area */
			margin-left: calc(40em - 50vw) !important;
			margin-right: calc(40em - 50vw) !important;
		}
	}
	@media screen and (min-width: 90em) {
		body:not(.toc-inline) .overlarge {
			/* 4em html margin 30.5em body padding 50em content area */
			margin-left: 0 !important;
			margin-right: calc(84.5em - 100vw) !important;
		}
	}

	@media not print {
		.overlarge {
			overflow-x: auto;
			/* See Lea Verou's explanation background-attachment:
			 * http://lea.verou.me/2012/04/background-attachment-local/
			 *
			background: top left  / 4em 100% linear-gradient(to right,  #ffffff, rgba(255, 255, 255, 0)) local,
			            top right / 4em 100% linear-gradient(to left, #ffffff, rgba(255, 255, 255, 0)) local,
			            top left  / 1em 100% linear-gradient(to right,  #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            top right / 1em 100% linear-gradient(to left, #c3c3c5, rgba(195, 195, 197, 0)) scroll,
			            white;
			background-repeat: no-repeat;
			*/
		}
	}
</style>
<style type="text/css">
    table, th, td {
      border: 1px solid black;
      border-collapse: collapse;
      vertical-align: top;
    }
    th, td {
      border-left: none;
      border-right: none;
      padding: 0px 10px;
    }
    th {
      text-align: center;
    }
  </style>
  <meta content="Bikeshed version 9c6ae748322940994300e90a77c34437364b40a6" name="generator">
  <link href="https://wg21.link/P1687R1" rel="canonical">
  <link href="https://isocpp.org/favicon.ico" rel="icon">
  <meta content="10943973b6a9de27d08cae2a1f17abb1214660e1" name="document-revision">
<style>
td {
  vertical-align: middle;
}
pre {
  margin-top: 0px;
  margin-bottom: 0px;
}
.ins, ins, ins *, span.ins, span.ins * {
  background-color: rgb(200, 250, 200);
  color: rgb(0, 136, 0);
  text-decoration: none;
}
.del, del, del *, span.del, span.del * {
  background-color: rgb(250, 200, 200);
  color: rgb(255, 0, 0);
  text-decoration: line-through;
  text-decoration-color: rgb(255, 0, 0);
}
math, span.math {
  font-family: serif;
  font-style: italic;
}
ul {
  list-style-type: "— ";
}
blockquote {
  counter-reset: paragraph;
}
div.numbered, div.newnumbered {
  margin-left: 2em;
  margin-top: 1em;
  margin-bottom: 1em;
}
div.numbered:before, div.newnumbered:before {
  position: absolute;
  margin-left: -2em;
  display-style: block;
}
div.numbered:before {
  content: counter(paragraph);
  counter-increment: paragraph;
}
div.newnumbered:before {
  content: "�";
}
div.numbered ul, div.newnumbered ul {
  counter-reset: list_item;
}
div.numbered li, div.newnumbered li {
  margin-left: 3em;
}
div.numbered li:before, div.newnumbered li:before {
  position: absolute;
  margin-left: -4.8em;
  display-style: block;
}
div.numbered li:before {
  content: "(" counter(paragraph) "." counter(list_item) ")";
  counter-increment: list_item;
}
div.newnumbered li:before {
  content: "(�." counter(list_item) ")";
  counter-increment: list_item;
}
</style>
<style>/* style-md-lists */

/* This is a weird hack for me not yet following the commonmark spec
   regarding paragraph and lists. */
[data-md] > :first-child {
    margin-top: 0;
}
[data-md] > :last-child {
    margin-bottom: 0;
}</style>
<style>/* style-counters */

body {
    counter-reset: example figure issue;
}
.issue {
    counter-increment: issue;
}
.issue:not(.no-marker)::before {
    content: "Issue " counter(issue);
}

.example {
    counter-increment: example;
}
.example:not(.no-marker)::before {
    content: "Example " counter(example);
}
.invalid.example:not(.no-marker)::before,
.illegal.example:not(.no-marker)::before {
    content: "Invalid Example" counter(example);
}

figcaption {
    counter-increment: figure;
}
figcaption:not(.no-marker)::before {
    content: "Figure " counter(figure) " ";
}</style>
<style>/* style-selflinks */

.heading, .issue, .note, .example, li, dt {
    position: relative;
}
a.self-link {
    position: absolute;
    top: 0;
    left: calc(-1 * (3.5rem - 26px));
    width: calc(3.5rem - 26px);
    height: 2em;
    text-align: center;
    border: none;
    transition: opacity .2s;
    opacity: .5;
}
a.self-link:hover {
    opacity: 1;
}
.heading > a.self-link {
    font-size: 83%;
}
li > a.self-link {
    left: calc(-1 * (3.5rem - 26px) - 2em);
}
dfn > a.self-link {
    top: auto;
    left: auto;
    opacity: 0;
    width: 1.5em;
    height: 1.5em;
    background: gray;
    color: white;
    font-style: normal;
    transition: opacity .2s, background-color .2s, color .2s;
}
dfn:hover > a.self-link {
    opacity: 1;
}
dfn > a.self-link:hover {
    color: black;
}

a.self-link::before            { content: "¶"; }
.heading > a.self-link::before { content: "§"; }
dfn > a.self-link::before      { content: "#"; }</style>
<style>/* style-autolinks */

.css.css, .property.property, .descriptor.descriptor {
    color: #005a9c;
    font-size: inherit;
    font-family: inherit;
}
.css::before, .property::before, .descriptor::before {
    content: "‘";
}
.css::after, .property::after, .descriptor::after {
    content: "’";
}
.property, .descriptor {
    /* Don't wrap property and descriptor names */
    white-space: nowrap;
}
.type { /* CSS value <type> */
    font-style: italic;
}
pre .property::before, pre .property::after {
    content: "";
}
[data-link-type="property"]::before,
[data-link-type="propdesc"]::before,
[data-link-type="descriptor"]::before,
[data-link-type="value"]::before,
[data-link-type="function"]::before,
[data-link-type="at-rule"]::before,
[data-link-type="selector"]::before,
[data-link-type="maybe"]::before {
    content: "‘";
}
[data-link-type="property"]::after,
[data-link-type="propdesc"]::after,
[data-link-type="descriptor"]::after,
[data-link-type="value"]::after,
[data-link-type="function"]::after,
[data-link-type="at-rule"]::after,
[data-link-type="selector"]::after,
[data-link-type="maybe"]::after {
    content: "’";
}

[data-link-type].production::before,
[data-link-type].production::after,
.prod [data-link-type]::before,
.prod [data-link-type]::after {
    content: "";
}

[data-link-type=element],
[data-link-type=element-attr] {
    font-family: Menlo, Consolas, "DejaVu Sans Mono", monospace;
    font-size: .9em;
}
[data-link-type=element]::before { content: "<" }
[data-link-type=element]::after  { content: ">" }

[data-link-type=biblio] {
    white-space: pre;
}</style>
 <body class="h-entry">
  <div class="head">
   <p data-fill-with="logo"></p>
   <h1 class="p-name no-ref" id="title">P1687R1<br>Summary of the Tooling Study Group’s Modules Ecosystem Technical Report Telecons</h1>
   <h2 class="no-num no-toc no-ref heading settled" id="subtitle"><span class="content">Published Proposal, <time class="dt-updated" datetime="2019-08-05">2019-08-05</time></span></h2>
   <div data-fill-with="spec-metadata">
    <dl>
     <dt>Authors:
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:brycelelbach@gmail.com">Bryce Adelstein Lelbach</a> (<span class="p-org org">NVIDIA</span>)
     <dd>
      <dd class="editor p-author h-card vcard"><a class="p-name fn u-email email" href="mailto:ben.craig@gmail.com">Ben Craig</a>
     <dt>Source:
     <dd><a href="https://github.com/brycelelbach/wg21_p1687_summary_of_tooling_study_group_modules_ecosystem_tr_telecons/blob/master/summary_of_tooling_study_group_modules_ecosystem_tr_telecons.bs">GitHub</a>
     <dt>Issue Tracking:
     <dd><a href="https://github.com/brycelelbach/wg21_p1687_summary_of_tooling_study_group_modules_ecosystem_tr_telecons/issues">GitHub</a>
     <dt>Project:
     <dd>ISO/IEC JTC1/SC22/WG21 14882: Programming Language — C++
     <dt>Audience:
     <dd>EWG, SG2, SG15
    </dl>
   </div>
   <div data-fill-with="warning"></div>
   <hr title="Separator for header">
  </div>
  <nav data-fill-with="table-of-contents" id="toc">
   <h2 class="no-num no-toc no-ref" id="contents">Table of Contents</h2>
   <ol class="toc" role="directory">
    <li><a href="#introduction"><span class="secno">1</span> <span class="content">Introduction</span></a>
    <li><a href="#summary-of-meetings"><span class="secno">2</span> <span class="content">Summary of Meetings</span></a>
    <li>
     <a href="#meeting-minutes"><span class="secno">3</span> <span class="content">Meeting Minutes</span></a>
     <ol class="toc">
      <li><a href="#meeting-minutes-2019-08-02"><span class="secno">3.1</span> <span class="content">2019-08-02 Meeting Minutes</span></a>
      <li><a href="#meeting-minutes-2019-06-21"><span class="secno">3.2</span> <span class="content">2019-06-21 Meeting Minutes</span></a>
     </ol>
   </ol>
  </nav>
  <main>
   <h2 class="heading settled" data-level="1" id="introduction"><span class="secno">1. </span><span class="content">Introduction</span><a class="self-link" href="#introduction"></a></h2>
   <p>At the ISO C++ Kona 2019 meeting, the ISO C++ Committee’s Tooling Study Group,
  SG15, met to discuss concerns raised by various stakeholders about how
  modules would impact and interact with the broader C++ ecosystem (build
  systems, tools, other languages, etc).
During that discussion, SG15 reached a consensus that the best way to prepare
  the C++ community for modules and ensure a smooth transition to modules over
  the next decade would be to prepare a <a href="https://wg21.link/P1688">C++ Modules Ecosystem Technical Report</a>.
At the ISO C++ Cologne 2019 meeting, the Evolution Working Group approved
  starting work on this Technical Report.</p>
   <p>The Tooling Study Group has held a series of telecons to work on the Technical
  Report.
This document contains a summary and detailed minutes for each of the telecons.</p>
   <h2 class="heading settled" data-level="2" id="summary-of-meetings"><span class="secno">2. </span><span class="content">Summary of Meetings</span><a class="self-link" href="#summary-of-meetings"></a></h2>
   <table>
    <tbody>
     <tr>
      <th width="15%">Meeting 
      <th width="45%">Agenda 
      <th width="40%">Organizers 
     <tr>
      <td> 2019-08-02 <a href="https://wg21.link/P1687R1#meeting-minutes-2019-08-02">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p><a href="https://wg21.link/P1838">D1838R0: Modules User-Facing Lexicon and
File Extensions</a>.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach.</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig.</p>
       </ul>
     <tr>
      <td> 2019-06-21 <a href="https://wg21.link/P1687R1#meeting-minutes-2019-06-21">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p><a href="https://wg21.link/P1788">P1788: Built Module Distribution</a> (Olga Arkhipova).</p>
        <li data-md>
         <p><a href="https://wg21.link/P1689">P1689: Dependency Format Specification</a> (Ben Boeckel).</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach.</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig.</p>
       </ul>
     <tr>
      <td> 2019-06-07 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-06-07">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>Plans for Pre-Cologne mailing papers.</p>
        <li data-md>
         <p>Compiled Module Configuration (Michael Spencer).</p>
        <li data-md>
         <p>New sg15@lists.isocpp.org mailing list.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach.</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig.</p>
       </ul>
     <tr>
      <td> 2019-05-24 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-05-24">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>Compiled Module Distribution (Olga Arkhipova).</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig</p>
       </ul>
     <tr>
      <td> 2019-05-10 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-05-10">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p><a href="https://wg21.link/P1634">P1634: Module Naming</a> (Corentin Jabot).</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Ben Craig</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig</p>
       </ul>
     <tr>
      <td> 2019-04-26 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-04-26">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>Distributed Build Systems (Ben Craig, Mathias Stearn).</p>
        <li data-md>
         <p>Clang Modules and Module Maps (Richard Smith).</p>
        <li data-md>
         <p>New sg15@lists.isocpp.org mailing list.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach</p>
        <li data-md>
         <p><em>Minute Taker:</em> Bryce Adelstein Lelbach, Ben Craig</p>
       </ul>
     <tr>
      <td> 2019-04-12 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-04-12">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>GCC Module Mapping:</p>
        <li data-md>
         <p><a href="https://wg21.link/P1184">P1184: A Module Mapper</a> (Nathan Sidwell).</p>
        <li data-md>
         <p><a href="https://wg21.link/P1602">P1602: Make Me A Module</a> (Nathan Sidwell).</p>
        <li data-md>
         <p>New sg15@lists.isocpp.org mailing list.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig</p>
       </ul>
     <tr>
      <td> 2019-04-05 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-04-05">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p><a href="https://wg21.link/P1689">P1689: Dependency Format Specification</a> (Ben Boeckel).</p>
        <li data-md>
         <p>Logistics of drafting the proposed C++ Ecosystem Technical Report
(format, repos, etc).</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig</p>
       </ul>
     <tr>
      <td> 2019-03-22 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-03-22">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>Suggested outline for the proposed C++ Ecosystem Technical.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Ben Craig</p>
        <li data-md>
         <p><em>Minute Taker:</em> Tom Honermann</p>
       </ul>
     <tr>
      <td> 2019-03-08 <a href="https://wg21.link/P1687R0#meeting-minutes-2019-03-08">Minutes</a> 
      <td>
       <ul>
        <li data-md>
         <p>Schedule for pre-Cologne Tooling Study Group telecons.</p>
        <li data-md>
         <p>Scope, priorities, and goals for the proposed C++ Ecosystem Technical Report.</p>
       </ul>
      <td>
       <ul>
        <li data-md>
         <p><em>Chairing:</em> Bryce Adelstein Lelbach</p>
        <li data-md>
         <p><em>Minute Taker:</em> Ben Craig</p>
       </ul>
   </table>
   <h2 class="heading settled" data-level="3" id="meeting-minutes"><span class="secno">3. </span><span class="content">Meeting Minutes</span><a class="self-link" href="#meeting-minutes"></a></h2>
   <p><strong>Minutes omitted from this revision can be found in prior revisions:</strong></p>
   <ul>
    <li data-md>
     <p><a href="https://wg21.link/P1687R0"><b>P1687R0: 2019-03-08 through 2019-06-07</b></a>.</p>
   </ul>
   <h3 class="heading settled" data-level="3.1" id="meeting-minutes-2019-08-02"><span class="secno">3.1. </span><span class="content">2019-08-02 Meeting Minutes</span><a class="self-link" href="#meeting-minutes-2019-08-02"></a></h3>
   <p><strong>Attendance:</strong></p>
   <ul>
    <li data-md>
     <p>Ben Craig</p>
    <li data-md>
     <p>Bryce Adelstein Lelbach (NVIDIA)</p>
    <li data-md>
     <p>Ben Boeckel (Kitware)</p>
    <li data-md>
     <p>Gabriel Dos Reis (Microsoft)</p>
    <li data-md>
     <p>Mathias Stearn</p>
    <li data-md>
     <p>Boris Kolpackov (build2)</p>
    <li data-md>
     <p>Bruno Lopes (Apple, Clang/LLVM)</p>
    <li data-md>
     <p>Tom Honermann (Synopsys)</p>
    <li data-md>
     <p>Rene Rivera (boost.build)</p>
    <li data-md>
     <p>Mark Zeren (VMWare)</p>
    <li data-md>
     <p>JF Bastien (Apple, Clang/LLVM)</p>
   </ul>
   <p><strong>Chair Notes (Bryce Adelstein Lelbach):</strong></p>
   <p>Agenda:</p>
   <ul>
    <li data-md>
     <p>2019-07 Cologne summary:</p>
     <ul>
      <li data-md>
       <p><a href="http://wiki.edg.com/bin/view/Wg21cologne2019/P1688R0-EWG">EWG review of P1688</a>.</p>
      <li data-md>
       <p><a href="http://wiki.edg.com/bin/view/Wg21cologne2019/SG15">Friday SG15 session</a>.</p>
     </ul>
    <li data-md>
     <p>2019-09-21 Denver CppCon meeting.</p>
    <li data-md>
     <p>Post-Cologne mailing (2019-08-05):</p>
     <ul>
      <li data-md>
       <p>P1687: Tooling Telecon Minutes (Bryce Adelstein Lelbach, Ben Craig).</p>
      <li data-md>
       <p>P1689: Dependency Information Format (Ben Boeckel).</p>
      <li data-md>
       <p>Generalized Module Mapper (Boris Kolpackov).</p>
     </ul>
    <li data-md>
     <p>D1838R0: Modules User-Facing Lexicon and File Extensions.</p>
     <ul>
      <li data-md>
       <p>CMI/BMI bikeshedding.</p>
      <li data-md>
       <p>File extensions.</p>
     </ul>
   </ul>
   <p><strong>POLL: Which names can you tolerate? (Vote as many times as you like)</strong></p>
   <table>
    <tbody>
     <tr>
      <th>Name 
      <th>Votes 
     <tr>
      <td>Binary Module Interface (BMI)
      <td>10 
     <tr>
      <td>Built Module Interface (BMI)
      <td>8 
     <tr>
      <td>Compiled Module Interface (CMI)
      <td>6 
     <tr>
      <td>PreCompiled Module (PCM)
      <td>4 
     <tr>
      <td>Module Interface Metadata (MIM)
      <td>3 
     <tr>
      <td>Module Interface Cache (MIC)
      <td>4 
     <tr>
      <td>Importable Module Artifact (IMA)
      <td>9 
   </table>
   <p><strong>POLL: Which name do you prefer?</strong></p>
   <table>
    <tbody>
     <tr>
      <th>Name 
      <th>Votes 
     <tr>
      <td>Binary Module Interface (BMI)
      <td>5 
     <tr>
      <td>Built Module Interface (BMI)
      <td>5 
     <tr>
      <td>Importable Module Artifact (IMA)
      <td>1 
   </table>
   <p><strong>CONSENSUS: We like the acronym BMI.</strong></p>
   <p>Action Items:</p>
   <ul>
    <li data-md>
     <p>Publish P1687R1 with minutes from the 2019-06-21 and 2019-08-02 telecon (Bryce).</p>
    <li data-md>
     <p>Publish new paper with details of the 2019-09-21 Denver CppCon meeting (Bryce).</p>
    <li data-md>
     <p>Share D1833R0 with everybody in the Tooling Study Group (Bryce).</p>
   </ul>
   <p><strong>Minutes (Ben Craig):</strong></p>
   <ul>
    <li data-md>
     <p>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.</p>
    <li data-md>
     <p>Bryce: Who is sending papers to the post-Cologne mailing (which is Monday)?</p>
    <li data-md>
     <p>Ben B: Planning on getting P1689 into the post meeting mailing.</p>
    <li data-md>
     <p>Boris: Planning on having a paper for generic module mapper.</p>
    <li data-md>
     <p>Bryce: Today we are discussing the modules lexicon paper. Want to have shared terminology in preparation for CppCon.</p>
    <li data-md>
     <p>Ben C: I just want consistency.</p>
    <li data-md>
     <p>Tom: I do like PCM because it’s sort of like precompiled headers.</p>
    <li data-md>
     <p>Gaby: Because of that, I would go in the opposite direction. Like CMI, since it doesn’t need to be stored in a binary form.</p>
    <li data-md>
     <p>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?</p>
    <li data-md>
     <p>Bryce: Some impls have distance steps for making obj and CMI, some impls have one step.</p>
    <li data-md>
     <p>Ben B: Fortran compilers use a single step for obj and CMI.</p>
    <li data-md>
     <p>General disagreement on which is more efficient.</p>
    <li data-md>
     <p>Mathias: Been thinking of obj production as "compiling" and CMI production as extracting.</p>
    <li data-md>
     <p>Gaby: Maybe "metadata" instead (module interface metadata?).</p>
    <li data-md>
     <p>Boris: What is meta about it? what is the data?</p>
    <li data-md>
     <p>Gaby: Prior art, it’s meta in the sense that it isn’t the .obj.</p>
    <li data-md>
     <p>Ben B: Module interface cache? Interfaces the transient nature.</p>
    <li data-md>
     <p>Gaby: Would need to distinguish the term in caching systems.</p>
    <li data-md>
     <p>Ben B: Importable Module Artifact?</p>
    <li data-md>
     <p>Boris: We should keep in mind that there are a lot of existing documents that use BMI.</p>
    <li data-md>
     <p>If we don’t have a significantly better term, we should prefer the status quo.</p>
    <li data-md>
     <p>If we want to be precise, then this doesn’t always apply to module, but also to headers.</p>
    <li data-md>
     <p>Bruno: I like binary because it could mean metadata or machine code, where compiled gives impression of machine code.</p>
   </ul>
   <p><strong>POLL: Which names can you tolerate? (Vote as many times as you like)</strong></p>
   <table>
    <tbody>
     <tr>
      <th>Name 
      <th>Votes 
     <tr>
      <td>Binary Module Interface (BMI)
      <td>10 
     <tr>
      <td>Built Module Interface (BMI)
      <td>8 
     <tr>
      <td>Compiled Module Interface (CMI)
      <td>6 
     <tr>
      <td>PreCompiled Module (PCM)
      <td>4 
     <tr>
      <td>Module Interface Metadata (MIM)
      <td>3 
     <tr>
      <td>Module Interface Cache (MIC)
      <td>4 
     <tr>
      <td>Importable Module Artifact (IMA)
      <td>9 
   </table>
   <ul>
    <li data-md>
     <p>Gaby: We’ll need to use this in the context of builds. When we talk about headers / modules, the word module might confuse things.</p>
   </ul>
   <p><strong>POLL: Which name do you prefer?</strong></p>
   <table>
    <tbody>
     <tr>
      <th>Name 
      <th>Votes 
     <tr>
      <td>Binary Module Interface (BMI)
      <td>5 
     <tr>
      <td>Built Module Interface (BMI)
      <td>5 
     <tr>
      <td>Importable Module Artifact (IMA)
      <td>1 
   </table>
   <ul>
    <li data-md>
     <p>BMI abbreviation seems to win.</p>
    <li data-md>
     <p>Rene: 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).</p>
    <li data-md>
     <p>Ben B: Why does it have to stand for anything? Just call it BMI.</p>
    <li data-md>
     <p>Bryce: Current status quo is that interface units have a different extension?</p>
    <li data-md>
     <p>Gaby: Only the interface has a different extension.</p>
    <li data-md>
     <p>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?</p>
    <li data-md>
     <p>Gaby: MSVC has distinct extensions to make other tools easier. Can’t change Visual Studio to not care about extension.</p>
    <li data-md>
     <p>Mathias: Not proposing that it doesn’t have an extension, just proposing that it doesn’t have a different extension.</p>
    <li data-md>
     <p>Gaby: Interfaces get treated a bit different from headers and implementation files. Treating an interface file as a header file isn’t adequate semantically.</p>
    <li data-md>
     <p>Tom: This is for driving build systems?</p>
    <li data-md>
     <p>Gaby: This is for driving the editor and the compiler. Without the extension, you need more compiler switches to disambiguate.</p>
    <li data-md>
     <p>Boris: @Bryce: I don’t believe GCC uses .cppm, I think you meant Clang? AFAIK, GCC/Nathan does not suggest a separate extension.</p>
    <li data-md>
     <p>Bryce: Overloading what .cpp means too much seems unnecessary.</p>
    <li data-md>
     <p>Gaby: Didn’t do this lightly in 2015.</p>
    <li data-md>
     <p>Different extension seems useful. Suggesting .cmi.</p>
    <li data-md>
     <p>Ben C: Cost to existing editors that don’t recognize the extension.</p>
    <li data-md>
     <p>Mark: Cost goes both ways, in that editors and tools can’t specialize.</p>
    <li data-md>
     <p>Mathias: Reduced scanning on non-importable units.</p>
    <li data-md>
     <p>Ben B: You have to scan anything that could import as well.</p>
    <li data-md>
     <p>Mathias: That would be my argument that you keep all the extensions the same,.</p>
    <li data-md>
     <p>since all need to be scanned anyway.</p>
    <li data-md>
     <p>Tom: Need to support build systems without a scan step. Whole world isn’t going to transition to cmake.</p>
    <li data-md>
     <p>Ben B: 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.</p>
    <li data-md>
     <p>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.</p>
    <li data-md>
     <p>Gaby: Implementation unit, I see .cpp and .mxx. GCC allows .cc and .cxx.</p>
    <li data-md>
     <p>Bryce: Not currently exhaustive. .cpp is a placeholder for all the existing extensions.</p>
    <li data-md>
     <p>Ben B: GCC uses gcm, gcmu, or gcms depending on the type.</p>
    <li data-md>
     <p>Boris: I think Nathan changed that.</p>
    <li data-md>
     <p>Ben B: Default module mapper uses CWD and makes up names, if you give it a module map, it uses that.</p>
    <li data-md>
     <p>Boris: @Bryce: with GCC you can write the BMI to any file (any name/extension, etc) using the module mapper.</p>
    <li data-md>
     <p>Bikeshedding over "Dependency Metadata" / "Dependency Information".</p>
    <li data-md>
     <p>Mathias: Rather not use implicit vs. explicit for this distinction. Explicit sounds like users are managing it.</p>
    <li data-md>
     <p>Maybe compiler managed, build system managed, user managed.</p>
    <li data-md>
     <p>Some discussion over merging Mathias’s categories.</p>
    <li data-md>
     <p>Gaby: Please don’t use the terms implicit and explicit terms for "Implicit Modules" and "Explicit Modules".</p>
    <li data-md>
     <p>Bryce: This should probably be considered anti-terminology.</p>
    <li data-md>
     <p>
      Ben C: Need different words for textual #include 
      <foo>
       , header unit #include 
       <foo>, and module import foo;.</foo>
      </foo>
     </p>
   </ul>
   <h3 class="heading settled" data-level="3.2" id="meeting-minutes-2019-06-21"><span class="secno">3.2. </span><span class="content">2019-06-21 Meeting Minutes</span><a class="self-link" href="#meeting-minutes-2019-06-21"></a></h3>
   <p><strong>Attendance:</strong></p>
   <ul>
    <li data-md>
     <p>Ben Craig</p>
    <li data-md>
     <p>Bryce Adelstein Lelbach (NVIDIA)</p>
    <li data-md>
     <p>Ben Boeckel (Kitware)</p>
    <li data-md>
     <p>David Blaikie (Google, Clang/LLVM)</p>
    <li data-md>
     <p>Rene Rivera (Boost.Build)</p>
    <li data-md>
     <p>JF Bastien (Apple, Clang/LLVM)</p>
    <li data-md>
     <p>Lukasz Mendakiewicz (Microsoft, MSVC)</p>
    <li data-md>
     <p>Nathan Sidwell (Facebook, GCC)</p>
    <li data-md>
     <p>Tom Honermann (Synopsys)</p>
    <li data-md>
     <p>Olga Arkhipova (Microsoft)</p>
    <li data-md>
     <p>Steve Downey</p>
    <li data-md>
     <p>Mark Zeren (VMWare)</p>
    <li data-md>
     <p>Michael Spencer (Apple, Clang/LLVM)</p>
    <li data-md>
     <p>Matthew Woelke (Kitware)</p>
    <li data-md>
     <p>Richard Smith (Google, Clang/LLVM)</p>
   </ul>
   <p><strong>Chair Notes (Bryce Adelstein Lelbach):</strong></p>
   <ul>
    <li data-md>
     <p>Agenda:</p>
    <li data-md>
     <p>New mailing list on lists.isocpp.org.</p>
    <li data-md>
     <p>Cologne prep</p>
     <ul>
      <li data-md>
       <p>Who actually sent papers?</p>
      <li data-md>
       <p>Review Ben’s Dependency Metadata Paper (P1689).</p>
      <li data-md>
       <p>Review Olga’s BMI Distribution Paper (P1788).</p>
      <li data-md>
       <p>Review Richard’s Packaging Paper (P1767).</p>
     </ul>
    <li data-md>
     <p>Next (last) Pre-Cologne call is July 5th (reschedule?).</p>
    <li data-md>
     <p>Pre-Cologne Papers (Send Drafts to sg15@lists.isocpp.org by 2019-06-14):</p>
    <li data-md>
     <p>P1687: Summary and Minutes of Pre-Cologne SG15 Discussions (Bryce, Ben C).</p>
    <li data-md>
     <p>P1688: Ecosystem Technical Report Outline (Bryce).</p>
    <li data-md>
     <p>P1689: Dependency Metadata (Ben B).</p>
    <li data-md>
     <p>P1788: Compiled Module Reuse (Olga, Lukasz).</p>
    <li data-md>
     <p>Module Naming (Corentin Jabot).</p>
    <li data-md>
     <p>Modules Hello World (Gaby).</p>
    <li data-md>
     <p>P1767: Modules and Packaging (Richard).</p>
    <li data-md>
     <p>RFE: (Paper or info on) Implicit Modules (Michael).</p>
     <ul>
      <li data-md>
       <p>Michael gave a talk at LLVM Euro about this.</p>
     </ul>
   </ul>
   <p><strong>Minutes (Ben Craig):</strong></p>
   <p>Ben Boeckel presents <a href="https://wg21.link/P1689">P1689</a>.</p>
   <ul>
    <li data-md>
     <p>Bryce: Did the unicode stuff come up last time, and did you talk to the unicode group?</p>
    <li data-md>
     <p>Ben B: It was discussed on slack.</p>
    <li data-md>
     <p>Tom: Worth a small presentation to SG16, looks like a good approach to the problem.</p>
    <li data-md>
     <p>Bryce: Unfortunate that this paper needs to deal with it, as it seems like a JSON problem.</p>
    <li data-md>
     <p>Tom: Beyond the scope of just json. It’s something that has come up in other contexts too.</p>
    <li data-md>
     <p>Bryce: working directory and chroot stuff is new, right?</p>
    <li data-md>
     <p>Ben B: yes.</p>
    <li data-md>
     <p>Ben B: future compile and future link are new. Want to be able to support #pragma comment for auto linking.</p>
    <li data-md>
     <p>Zeren: How important is windows auto linking? We rip it out of boost.</p>
    <li data-md>
     <p>Ben B: It came up in slack, I’m not super attached to it.</p>
    <li data-md>
     <p>Olga: I don’t know if it’s needed.</p>
    <li data-md>
     <p>Nathan: Could be something in vendor extensions.</p>
    <li data-md>
     <p>Ben B: vendor extensions are supposed to be ignorable.</p>
    <li data-md>
     <p>Ben B: May be able to leave auto linking out of the first version.</p>
    <li data-md>
     <p>Ben C: Maybe std::embed like cases?</p>
    <li data-md>
     <p>Ben B: I don’t think a C++ file mentions linker embedded things.</p>
    <li data-md>
     <p>Ben C: Agreed. Withdrawn.</p>
    <li data-md>
     <p>Tom: Seems like a good vendor extension to me.</p>
    <li data-md>
     <p>Bryce: Doesn’t seem to come up with our weird heterogenous context.</p>
    <li data-md>
     <p>Rene: shouldn’t the vendor extensions say whether it is required or not?</p>
    <li data-md>
     <p>Ben B: For vendor extensions, if it is required and necessary for a correct build, then we wouldn’t know how to turn that into something to make ninja or make work.</p>
    <li data-md>
     <p>Bryce: Similar to C++ attributes.</p>
    <li data-md>
     <p>Tom: These are intended to be transient files. Not meant to be shipped out. May even be piped and not stored on file system.</p>
    <li data-md>
     <p>Ben B: yes.</p>
    <li data-md>
     <p>Bryce: Never seen anyone store off a makefile database to be used later.</p>
    <li data-md>
     <p>Rene: I have.</p>
    <li data-md>
     <p>Rene: The unreal build system will serialize out some intermediate files and use the same one repeatedly.</p>
    <li data-md>
     <p>Bryce: Just trying to ensure that the intent is that this file doesn’t go into source control.</p>
    <li data-md>
     <p>Ben B: tup is a build tool where each rule gets a chroot, they will need to use the working directory in interesting ways.</p>
   </ul>
   <p>Olga and Lukasz present <a href="https://wg21.link/P1788">P1788</a>.</p>
   <ul>
    <li data-md>
     <p>Bryce: Have LLVM people had a chance to see the paper?</p>
    <li data-md>
     <p>Spencer: Yes, mostly makes sense. Nothing in here surprising or hard?</p>
    <li data-md>
     <p>Tom: Looking at the recommendation to library vendors, does LLVM agree that it is ok to ship BMIs as an optimization?</p>
    <li data-md>
     <p>Spencer: Yes, that’s fine. BMI as an optimization is fine.</p>
    <li data-md>
     <p>Tom: Will you ignore them if they are inappropriate?</p>
    <li data-md>
     <p>Spencer: You will get an error if you give us a bad one explicitly, we will rebuild if it is implicit. We can’t easily rebuild for explicit, because we don’t know how to build it correctly.</p>
    <li data-md>
     <p>Tom: You could ask the BMI how to build it.</p>
    <li data-md>
     <p>Ben C: But that information is only how to build that BMI, now how to build it correctly.</p>
    <li data-md>
     <p>Richard S: Including env and working directory could be trouble. We need bit for bit build reproducability, even when different working directories are used to build on different machines.</p>
    <li data-md>
     <p>Tom: May also need to include which important env variables are unset, so that those can be cleared.</p>
    <li data-md>
     <p>David: Distributing prebuilt modules as an optimization... sounded like a bit of a disconnect. In explicit modules world, the scanning or oracle system would need to be able to see if those BMIs are suitable or not. If the prebuilt modules are good, the scan would report that prebuilt module.</p>
    <li data-md>
     <p>Nathan: I’ve started putted in human readable section of BMI things like working directory. It doesn’t effect the CRCs, and those sections could be stripped to possibly get bit for bit reproducability.</p>
    <li data-md>
     <p>Bryce: Is this something that GCC can get on board with?</p>
    <li data-md>
     <p>Nathan: Putting information to rebuild from source may only want to be done explicitly, because it might be expensive, and it might be a secret.</p>
    <li data-md>
     <p>Tom: Would you be amenable to adding an ENV variable to get that information into a BMI.</p>
    <li data-md>
     <p>Tom: Intent is that all of the source needs to get into a BMI. Particularly because of header files that went into it.</p>
    <li data-md>
     <p>Nathan: Already hit issues where header files of library on producing machine are different from header files on consuming machine.</p>
    <li data-md>
     <p>Tom: We really need all the source.</p>
    <li data-md>
     <p>Olga: Could include the header file paths.</p>
    <li data-md>
     <p>Tom: But those files may not be available on the consuming machine.</p>
    <li data-md>
     <p>Lukasz: Debugger has some hashes. May want to be able to ignore whitespace changes.</p>
    <li data-md>
     <p>Olga: Directory structure of location where BMI is built may be different than directory structure where BMI is used?</p>
    <li data-md>
     <p>Olga: If you can’t find those files using the command line, then full paths won’t help. Are you asking for the BMI to include the source itself?</p>
    <li data-md>
     <p>Nathan: compiler vendors may want that to be able to deal with bug reports.</p>
    <li data-md>
     <p>Matthew W: Should be a way for linux distros to point to them instead of vendoring them.</p>
    <li data-md>
     <p>Nathan: My experience is with multiple red hat based systems that are still different enough to cause problems.</p>
    <li data-md>
     <p>Matthew W: Wanted to go back and say something about whether you can use a prebuilt BMI. I would punt on the problem. Wouldn’t have the scanning tool fix it. Let the compiler have something like ccache sitting in front of it that looks in a cache to see if the compile line is compatible. If it’s not there then it can be built at that time.</p>
    <li data-md>
     <p>Steve D: Anyone shipping a BMI has to be prepared to have consumers rebuild the BMI. It’s an important optimization, but the BMI can’t be trusted... you need to be ready to scrap it and rebuild it.</p>
    <li data-md>
     <p>Bryce: Main point of contentions are the "Other build options" bullet point and "module source" bullet point.</p>
    <li data-md>
     <p>Olga: Those things can be ignored by users, but I need to think about it.</p>
    <li data-md>
     <p>Tom: There are certainly copyright concerns.</p>
   </ul>
  </main>
<script>
(function() {
  "use strict";
  var collapseSidebarText = '<span aria-hidden="true">←</span> '
                          + '<span>Collapse Sidebar</span>';
  var expandSidebarText   = '<span aria-hidden="true">→</span> '
                          + '<span>Pop Out Sidebar</span>';
  var tocJumpText         = '<span aria-hidden="true">↑</span> '
                          + '<span>Jump to Table of Contents</span>';

  var sidebarMedia = window.matchMedia('screen and (min-width: 78em)');
  var autoToggle   = function(e){ toggleSidebar(e.matches) };
  if(sidebarMedia.addListener) {
    sidebarMedia.addListener(autoToggle);
  }

  function toggleSidebar(on) {
    if (on == undefined) {
      on = !document.body.classList.contains('toc-sidebar');
    }

    /* Don’t scroll to compensate for the ToC if we’re above it already. */
    var headY = 0;
    var head = document.querySelector('.head');
    if (head) {
      // terrible approx of "top of ToC"
      headY += head.offsetTop + head.offsetHeight;
    }
    var skipScroll = window.scrollY < headY;

    var toggle = document.getElementById('toc-toggle');
    var tocNav = document.getElementById('toc');
    if (on) {
      var tocHeight = tocNav.offsetHeight;
      document.body.classList.add('toc-sidebar');
      document.body.classList.remove('toc-inline');
      toggle.innerHTML = collapseSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, 0 - tocHeight);
      }
      tocNav.focus();
      sidebarMedia.addListener(autoToggle); // auto-collapse when out of room
    }
    else {
      document.body.classList.add('toc-inline');
      document.body.classList.remove('toc-sidebar');
      toggle.innerHTML = expandSidebarText;
      if (!skipScroll) {
        window.scrollBy(0, tocNav.offsetHeight);
      }
      if (toggle.matches(':hover')) {
        /* Unfocus button when not using keyboard navigation,
           because I don’t know where else to send the focus. */
        toggle.blur();
      }
    }
  }

  function createSidebarToggle() {
    /* Create the sidebar toggle in JS; it shouldn’t exist when JS is off. */
    var toggle = document.createElement('a');
      /* This should probably be a button, but appearance isn’t standards-track.*/
    toggle.id = 'toc-toggle';
    toggle.class = 'toc-toggle';
    toggle.href = '#toc';
    toggle.innerHTML = collapseSidebarText;

    sidebarMedia.addListener(autoToggle);
    var toggler = function(e) {
      e.preventDefault();
      sidebarMedia.removeListener(autoToggle); // persist explicit off states
      toggleSidebar();
      return false;
    }
    toggle.addEventListener('click', toggler, false);


    /* Get <nav id=toc-nav>, or make it if we don’t have one. */
    var tocNav = document.getElementById('toc-nav');
    if (!tocNav) {
      tocNav = document.createElement('p');
      tocNav.id = 'toc-nav';
      /* Prepend for better keyboard navigation */
      document.body.insertBefore(tocNav, document.body.firstChild);
    }
    /* While we’re at it, make sure we have a Jump to Toc link. */
    var tocJump = document.getElementById('toc-jump');
    if (!tocJump) {
      tocJump = document.createElement('a');
      tocJump.id = 'toc-jump';
      tocJump.href = '#toc';
      tocJump.innerHTML = tocJumpText;
      tocNav.appendChild(tocJump);
    }

    tocNav.appendChild(toggle);
  }

  var toc = document.getElementById('toc');
  if (toc) {
    createSidebarToggle();
    toggleSidebar(sidebarMedia.matches);

    /* If the sidebar has been manually opened and is currently overlaying the text
       (window too small for the MQ to add the margin to body),
       then auto-close the sidebar once you click on something in there. */
    toc.addEventListener('click', function(e) {
      if(e.target.tagName.toLowerCase() == "a" && document.body.classList.contains('toc-sidebar') && !sidebarMedia.matches) {
        toggleSidebar(false);
      }
    }, false);
  }
  else {
    console.warn("Can’t find Table of Contents. Please use <nav id='toc'> around the ToC.");
  }

  /* Wrap tables in case they overflow */
  var tables = document.querySelectorAll(':not(.overlarge) > table.data, :not(.overlarge) > table.index');
  var numTables = tables.length;
  for (var i = 0; i < numTables; i++) {
    var table = tables[i];
    var wrapper = document.createElement('div');
    wrapper.className = 'overlarge';
    table.parentNode.insertBefore(wrapper, table);
    wrapper.appendChild(table);
  }

})();
</script>