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

[Daniel Ruoso via Phabricator via libcxx-commits]

ruoso added inline comments.


================
Comment at: libcxx/docs/Modules.rst:136
+The modules will shipped in a directory structure similar to the include.
+Includes are stored in ``<PREFIX>/modules/c++/v1`` modules will be stored in
+``<PREFIX>/modules/c++/v1/``.
----------------
ruoso wrote:
> aaronmondal wrote:
> > tschuett wrote:
> > > I believe this is confusing. I thought that you want to store everything underneath `c++`? Additionally you use the same path  for includes and modules.
> > Typo? Should probably be "Includes are stored in `<prefix>/include/c++/v1`, modules in `<prefix>/modules/c++/v1`".
> > 
> > I think this makes sense. Modules can't be `#include`d anyways so there is a need for them to live in an `include/` directory. And for those using a different ABIs this leaves the possibility to have
> > ```
> > .../include/c++/v1
> > .../include/c++/v2
> > .../modules/c++/v1
> > .../modules/c++/v2
> > ```
> > or similar to clearly differentiate the headers/module interfaces.
> `$PREFIX/modules` is a new path that doesn't exist in the Filesystem Hierarchy Standard.
> 
> The source files for the module units is indeed a arch-independent resource, therefore the correct directory would be something under `$PREFIX/share`
> 
> If we ever intend to ship BMI files, they would belong in `$libdir`.
> 
> Here's how it would look like if we go in that direction:
> 
> ```
> $PREFIX/
>    $libdir/
>        libc++.so
>        libc++.so.module-info
>        c++/
>            modules/
>                 libc++/
>                       std.gcm.deadbeef1234
>    share/
>        c++/
>            modules/
>                  libc++/
>                        std.cppm
> ```
> 
> the `libc++.so.module-info` file would have the metadata necessary for someone to understand how to produce their own BMI as well as potentially reuse the shipped BMI if it just so happen that they can.
There is one important bit that worries about splitting off the source files, tho.

The module metadata shipped alongside the library itself needs to reference those source files, and I am concerned that requiring the use of `../../../../share/` in order to address the source location can lead to fragility in the deployment.

So, even though it's technically arch-independent, I would also consider the following option:

```
$PREFIX/
   $libdir/
       libc++.so
       libc++.so.module-info
       c++/
           modules/
                libc++/
                      std.gcm.deadbeef1234
                      std.cppm
```

Because at that point, the metadata could reference a relative path from the library location without the awkwardness that using `../` can cause when directories are symlinks.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144994