[libcxx-commits] [PATCH] D144994: [Draft][libc++][modules] Adds std module.

[Mark de Wever via Phabricator via libcxx-commits]

Mordante added a comment.

In D144994#4170655 <https://reviews.llvm.org/D144994#4170655>, @ChuanqiXu wrote:

> About distributing the std modules, this is what we do in the downstream:
>
>   # std-module.spec
>   
>   ...
>   
>   Requires: clang_xxx # for example clang17
>   
>   %prep
>   %build
>   %install
>   
>   mkdir -p <path-to-the-install-destination-of-std-module>
>   cp `.cppm` files to  <path-to-the-install-destination-of-std-module>
>   cp ../../../build.sh <path-to-the-install-destination-of-std-module>
>   
>   ...
>   
>   %post
>   <path-to-the-install-destination-of-std-module>/build.sh
>
> The commands line after `%post`  will execute the corresponding instructions when the user input `yum install std-modules` and the build.sh contains the instructions to compile the std modules.
>
> Then in our downstream, we will hardcode the `<path-to-the-install-destination-of-std-module>` to the compiler to lookup the `.pcm` files and linking libraries. Hope the sharing helps.
>
> ---

This is somewhat along the lines what I am thinking about too. However I use a CMake file for users. One of the issues in libc++ is that vendors can decide to disable filesystem header. Since parts of that library are in the dylib the `std` module can't provide what's in filesystem. Does your method also have that feature?

> From my understanding, we can't do the above things easily in the open-source community like LLVM. There should be some more discussing about this. So I suggest that the current patch shouldn't care about installation and distribution. It will be good enough if we have an available std module which pass the tests. Then we can discuss about the installation and distribution step by step.

I think we can discuss that and see whether it's a blocker for landing the patch or not. For now I still have issues with ranges (which I have not started to investigate). I have been experimenting with running the test-suite for the modular build. So I will have some more information on that later today, probably on Discord.



================
Comment at: libcxx/docs/Modules.rst:42
+   not handle that case properly.
+ * There is no `P1689 style output <https://wg21.link/P1689>`_ yet.
+ * The experimental library (read <format>) does not work as expected
----------------
aaronmondal wrote:
> ChuanqiXu wrote:
> > Mordante wrote:
> > > ChuanqiXu wrote:
> > > > Mordante wrote:
> > > > > ChuanqiXu wrote:
> > > > > > P1689 format is supported in clang-scan-deps. What's the reason we can't make it now?
> > > > > We can make it, that's no problem. However that file needs the use the installation path and not the path in the build directory. So the output needs a search and replace, but I don't know yet what the proper replace value will be.
> > > > > 
> > > > > I put this item here so we don't forget about including it.
> > > > I still don't understand. No matter where the source files is, the output of P1689 format should be generated during the building and I think we shouldn't port them.
> > > Using 
> > > `clang-scan-deps-17  -format=p1689 -compilation-database compile_commands.json`
> > > The output looks like
> > > ```
> > > {
> > >   "revision": 0,
> > >   "rules": [
> > >     {
> > >       "primary-output": "CMakeFiles/std.dir/std-coroutine.cppm.o",
> > >       "provides": [
> > >         {
> > >           "is-interface": true,
> > >           "logical-name": "std:coroutine",
> > >           "source-path": "<build-dir>/include/c++/modules/std-coroutine.cppm"
> > >         }
> > >       ]
> > >     },
> > > ```
> > > Where `<build-dir>` is the place where I copied the `cppm` files to. This output seems quite useless, since it's tied to a specific machine. Do you have suggestions how to get less my-system-specific paths?
> > Yeah, the `<build-dir>` is tied to specific machine. But why is it a problem? From my mind, we will distribute the `*.cppm` files like the header files. Then the users' build system  will generate the `P1689` output according to the `*.cppm` files in their machine. I think the key point here is that the `P1689` output is a by-product of the building process and we (users) don't need to care about it.
> > 
> Hmm `P1689` states that these files assume
> 
> > uniformity of the environment between creation and usage; only used within one build of a project
> 
> AFAIU the `P1689` output is not supposed to be distributed to users. It's supposed to be generated and consumed during the same build.
Let's discuss this further in an upcoming meeting. I don't object against not shipping it.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D144994/new/

https://reviews.llvm.org/D144994