On Thu, Jul 6, 2023 at 7:00 PM Ben Boeckel via SG15 <sg15_at_[hidden]>
wrote:

> On Sun, Jul 02, 2023 at 17:41:29 +0200, Mark de Wever via SG15 wrote:
> > I'm a libc++ developer working on implementing the std and the
> > std.compat module. I have an experimental version of the std module [1].
> > Using the module requires manually building the BMI using the files in
> > the local libc++ build directory. This works for early adaptors, but is
> > not a solution that can be used in production.
> >
> > For example, Apple uses ${SDKROOT} as ${PREFIX} where it's an empty
> > string on Linux systems.
>
> A nitpick, but `${PREFIX}` usually handles the `/usr` on Unix platforms
> (e.g., `/usr/local` is impossible with the proposed pattern as-is).
> Apple can do whatever they do today to reroot under the SDK as they do
> for everything else that gets installed (I suspect there's some DESTDIR
> and longer PREFIX settings, but that's just a guess). The SDKs are all
> relocatable anyways, so there's not really a set place beyond "what does
> the compiler think the SDK root is?" whether that be set via
> `xcodeselect` or `DEVELOPER_DIR`).
>
> > The <library> is the name of the library where every name starting with
> > the library name is reserved. Some examples:
> >
> > ${PREFIX}/usr/share/c++/modules/libc++/v1/std.cppm
> > ${PREFIX}/usr/share/c++/modules/libc++/v1/std.compat.cppm
> >
> > ${PREFIX}/usr/share/c++/modules/libstdc++/14/std.cppm
> > ${PREFIX}/usr/share/c++/modules/libstdc++/14/std.compat.cppm
> >
> > ${PREFIX}/usr/share/c++/modules/qt/core.cppm
> > ${PREFIX}/usr/share/c++/modules/qt/network.cppm
> >
> > ${PREFIX}/usr/share/c++/modules/boost181/boost.cppm
> > ${PREFIX}/usr/share/c++/modules/boost182/boost.cppm
> >
> > In the latter case the boost181 and boost182 belong to the boost
> > library namespace.
>
> I think it's not just a nitpick, but gets at the heart of the expectations
about the FHS. Stuff installed under a FHS $PREFIX are (intended to be) an
integrated whole. Unless you expect to have an include/boost181, it would
be surprising to have a share/c++/modules/boost181. That also suggests that
share/c++/modules isn't the right place generally? I don't see why
installing into include/c++/v1 -> ../../lib/llvm-16/include/c++/v1 wouldn't
be OK for clang/libc++ ?

Pkgconfig library descriptions seem to mostly go into,
e.g., /usr/lib/x86_64-linux-gnu/pkgconfig/ so I would expect the richer
configs we're proposing would go somewhere similar, the contents of which
would explain where the interfaces are which need to be translated.