[PATCH] D135345: [libunwind] Add module maps for libunwind

Mon Oct 24 13:32:22 PDT 2022

iana added a comment.

In D135345#3880528 <https://reviews.llvm.org/D135345#3880528>, @ldionne wrote:

> In D135345#3851537 <https://reviews.llvm.org/D135345#3851537>, @MaskRay wrote:
>
>> I think the default name `module.modulemap` (loaded by `-fimplicit-module-maps`) is more appropriate for the upstream and it helps layering check features in Clang.
>> The name `libunwind.modulemap` is indeed special and seems to platform specific. I don't know how to assess `compact_unwind_encoding.modulemap` and the `MachO.*` name instead of `libunwind.*`/`unwind.*`.
>
> Does that mean that no library rooted at `/usr/include` can provide its own modulemap? For example, libc++ provides its own modulemap and calls it `module.modulemap`, but it can do that because it is rooted at `/usr/include/c++/v1`. If it were rooted at `/usr/include`, it would collide with any other system-provided `module.modulemap` file (arguably like a C standard library modulemap).

Yes that's correct. There can be only one owner per directory, and libunwind doesn't own `/usr/include`. All it can do is provide a module map that the owner can include from `module.modulemap`.

> I am not sure that the current convention of calling those files `module.modulemap` makes sense, but I'm happy to be corrected.

That's just the compiler magic name.

> libc++ does have a modulemap that it provides for all platforms and this is upstream -- I don't see why libunwind should be any different, but again I am happy to be corrected.

libc++ owns `/usr/include/c++/v1`, and thus owns `/usr/include/c++/v1/module.modulemap` which it indeed provides. libunwind must be different, because it doesn't own any directories at all.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D135345