I hope we use package granularity instead of module granularity...

-- Gaby

________________________________
From: Steve Downey <sdowney_at_[hidden]>
Sent: Tuesday, July 11, 2023 8:05:07 AM
To: sg15_at_[hidden] <sg15_at_[hidden]>
Cc: Gabriel Dos Reis <gdr_at_[hidden]m>; Mark de Wever <koraq_at_[hidden]>; Louis Dionne <ldionne_at_[hidden]>; Casey Carter <casey.carter_at_[hidden]>; Aaron Mondal <aaron_at_[hidden]>; Stephan T. Lavavej <stl_at_[hidden]>; Chuanqi Xu <yedeng.yd_at_[hidden]>
Subject: Re: [SG15] Provide build systems with ways to build the std(.compat) modules

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]<mailto: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]<mailto:SG15_at_[hidden]>
https://lists.isocpp.org/mailman/listinfo.cgi/sg15