C++ Logo

sg15

Advanced search

Re: [Modules] Should the compiler try to build std module implicitly?

From: Ran Regev <regev.ran_at_[hidden]>
Date: Mon, 4 Dec 2023 09:34:15 +0200
On Mon, Dec 4, 2023, 08:00 Chuanqi Xu via SG15 <sg15_at_[hidden]>
wrote:

> Hi Guys,
>
> This post is mainly about some random thoughts about teachability of
> std modules. Also [P2412R0: Minimal module support for the standard
> library] (
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2412r0.pdf)
> mentions that the std module is important for educations and beginners. If
> there are more interests, I can try to summarize them into a paper.
>
> When I start to learn C++, I only need to copy a hello world example
> and run:
> ```
> clang++ hello.cpp -o hello
> ```
>

If the code of hello.cpp is similar to the example below (just include
instead of import) then even in this example the compiler did a "magic" for
you by finding this include without your specific direction. It simply
"knew" where to search.


> However, with the current direction of std modules, the beginner need
> to install the build systems and try to copy the build scripts that them
> can hardly understand. Possibly some simpler form of
> https://libcxx.llvm.org/Modules.html. But it still seems scaring to
> beginners.
>

The same mechanism that is used by compilers to find includes may be used
to find modules.

>
> And I am wondering if we can simplify the process. For example, the
> beginners can compile a hello world example with std module:
> ```
> import std;
> int main() { std::cout << "Hello modular world\n"; }
> ```
> with a single command line:
> ```
> clang++ -std=c++23 hello.cpp -o hello
> ```
>
> The compiler may achieve that when:
> - the std module is required but not provided.
> - the path to std module's BMI is not specified. (implied that the
> invocation doesn't from build systems)
> - the final output is an executable.
> - the std module's source exists in the installed path (being discussed in
> https://github.com/llvm/llvm-project/issues/73089).
>

I am not sure we must start with the source code of every library we want
to import (including the standard). It feels like that if we had a place
for BMIs then we are good to go using them. There is a question what to do
when they are missing. Maybe an error, not trying to build from source.

>
> then the compiler can try to compile the std module's source to BMI and
> object file. Then we can import the BMI and link the object file. There are
> some details. e.g., where should we put the BMI?
>
In the BMI-well-known-place (like headers).

Should we try to reuse the BMIs?
>
Yes.

Can we extend the process to other modules?
>
Sure. Without this ability we are doing wrong. Std shouldn't be special.

They are open questions and my answers are:
> - By default, they should be in `/tmp` and if `-save-temps` is specified,
> they'll be in the same directory with the temporaries.
>
I don't agree. BMI should be reused as far as I understand.

- The compiler shouldn't try to reuse the BMIs. That is the job of the
> build systems.
>
I think that as source files are the input of #incluse, BMI should be the
input of import. Therefore the compiler should try and find ONLY BMIs when
it sees import directive. It is the build system to make sure they exists.

- No, we can't. It is possible for std module since we'll try to
> standardize the locations of std modules sources. So that the tools are
> able to find the source of std modules. But it is not the case for other
> generalized modules. Also I think this is the job of build systems too.
>
I disagree. Std and other modules should behave the same.

>
> The motivation is primarily for beginners and educations. How do you feel
> about the idea?
>
> Thanks,
> Chuanqi
>
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>

Received on 2023-12-04 07:34:29