I'd expect they would want a really strong argument for adding a new
top-level directory since there's going to be all sorts of knock-on effects
for sysadmins, like does it need a separate physical FS, what the backup
strategy is, and so on. If the answer is 'the same as usr/include' we
probably have to answer why it isn't just that. And, more importantly, the
timeframe for FHS 4.0 is way out of our control, and we need an answer for
systems today.

`usr/share/c++/module/{module-name}` ? I'm picking module-name rather than
package name to help reify a name collision in a detectable place.

Windows tends to look more like `opt/` packaging, though? That is, packages
are unrolled onto disk in their own, non-shared, location?

In any case, I think the bootstrap process I've been envisioning, where the
metadata for a package is predictably findable from the package name, and
that gives you the usage information. The way that pkgconfig is used today.
Some packages involve multiple physical libraries, so we may not want to
tie the metadata to the .a / .lib file?


On Sun, Jul 9, 2023 at 8:22 AM Mark de Wever via SG15 <sg15_at_[hidden]>
wrote:

> On Fri, Jul 07, 2023 at 06:04:38PM +0000, Gabriel Dos Reis wrote:
> > [Mark]
> > > The proposed path seems not a good path for Windows. I hope the
> > > Microsoft developers have a suggestion. Would it be possible for other
> > > libraries to match with MSVC STL does?
> >
> > For context, MSVC puts the Standard Library Modules in a directory
> > named "modules/" sibling to the "include/" directory for standard
> > headers. That is the contract with MSVC users and all devtools
> > targeting MSVC.
>
> This was one of the proposals in the LLVM discourse too. There were some
> concerns with the land grab of /usr/modules on Linux. I don't know
> whether the Filesystem Hierarchy Standard group will object against this
> idea. I see less issues with this approach on Windows systems.
>
> > See for example, what I did here:
> https://github.com/GabrielDosReis/cmake-for-modules/blob/main/CXXModuleExperimentalSupport.cmake
>
> Thanks.
>
> Cheers,
> Mark
> _______________________________________________
> SG15 mailing list
> SG15_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg15
>