I think it would be useful to finish the discussion about scenarios and assumptions before we go to solutions

 

Here is what I believe we’ve got so far

 

Suppose we have:

 

Library A: contains Module A

Library B: contains Module B which imports Module A

Code C: imports Module B

 

The libraries can come in different forms:

 

  1. Binary Libraries – libraries that contain prebuilt BMIs and static lib (as well as at least some sources)
  2. Source Libraries – libraries that don’t contain any binaries, most of the popular libraries today. There are two main forms today

b.1. Header only libraries  – headers are built as a part of the user’s code TUs.

   Note: This form is not applicable to module interfaces as they are different TUs. The module interface source will have to be built explicitly (i.e. it has to be b.2).

b.2. Sources and (some) build instructions  - sources are built on the user’s machine with user’s build tools (producing static or dynamic lib) which then consumed by the user’s build.

  The build is performed either by the package manager or by user’s build explicitly. The result and further usage is similar to Binary Libraries.

 

Scenarios and assumptions

 

  1. Main build of C.

1.1   The build needs to have Module B’s and Module A’s BMIs to be able to compile the source that import Module B.

The build needs to

1.1.1.        find BMIs in the  (assuming it can read them) using the information available to that build system

or

1.1.2.        somehow re-build the BMIs (assuming it cannot read them).

 

1.2.      The build also needs to find and link static lib of Library B (which contains implementation of Module B), as well as static lib of Library A (which contains implementation of Module A).

 

  1. Tools outside of the main build (IDE, static analysis, etc.) need to compile/parse C.

Assumption: the main build of C succeeds on the same machine.

For that they need to be able to rebuild Module A and Module B (the assumption is that they never can read BMIs).

 

 

What we’ve agreed on:

 

  1. Any library which contains modules must include module interface sources
  2. If a library contains BMIs, it should also contain information (probably in some json form) sufficient to be able to rebuilt them.

 

 

I also promised a description of what VS is doing for module’s build, please see attached.

 

Thanks,

Olga

 

 

From: SG15 <sg15-bounces@lists.isocpp.org> On Behalf Of Michael Spencer via SG15
Sent: Tuesday, March 1, 2022 10:11 AM
To: Tooling Study Group (SG15) <sg15@lists.isocpp.org>
Cc: Michael Spencer <bigcheesegs@gmail.com>
Subject: [SG15] Meeting on Friday March 4th at 9AM Pacific.

 

Our next meeting is scheduled for Friday March 4th at 9AM-10:30AM Pacific.

 

Our topics for this meeting will be:

* https://wg21.link/p2473r1 - Distributing C++ Module Libraries

* https://wg21.link//P2536R0 - Distributing C++ Module Libraries with dependencies json files.

 

Meeting Link: https://iso.zoom.us/j/97089073839?pwd=WHdxbzE0cTFkOU1aVWZocjhkSnp2dz09