>> My secret goal is for us to make the std modules look just like any named modules without any special cases.
STL modules are part of the library and this makes them different from user's code modules. I think it would be good to mention them.
But yes, ideally, STL should not be different from other source only libraries and have similar manifest, which would be used by build/packaging to discover and build its modules.

Olga

From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniel Ruoso via SG15
Sent: Monday, October 16, 2023 1:30 AM
To: sg15_at_[hidden]
Cc: Daniel Ruoso <daniel_at_[hidden]>
Subject: Re: [SG15] [P2990R0]: C++ Modules Roadmap

On Mon, Oct 16, 2023, 04:21 Chuanqi Xu via SG15 <sg15_at_[hidden]<mailto:sg15_at_[hidden]>> wrote:
In 2.1, it should be `P1689R5` instead of `P1689R4` as far as I know.

Ack, will fix.

But as far as I know, all the compilers require to compile the module interface unit to object files and link that.

Yes, clang was the only one I verified the behavior. But I was aware of the convergence there. I'll change the wording a little bit to clarify that.

For 2.3.1, I am trying to support C++20 modules in clangd: https://github.com/llvm/llvm-project/pull/66462. But I understand it is OK to not mention it since it is not landed. I just mention it here FYI.

I'll add the context. I was not aware of that. Thanks.

For 3.4, from my experience in clangd, it looks sufficient to have the existing compilation database and a map from module name to the source files for the static analyzing tools to create BMIs for their own.

This is in line with the other discussion. We also need to support "local processor arguments".

Also I am suggesting to add a section for the current state of std module in some places of section2.

My secret goal is for us to make the std modules look just like any named modules without any special cases.

But, I'm opening to adding that more explicitly to the roadmap.

Daniel