On Tue, Jul 11, 2023 at 11:05:07AM -0400, Steve Downey wrote:
> 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.
 
I still feel it doesn't belong to usr/include, but if that is the most
practical way to move forward I'm not SA. The decision we make today
will be "forever", so I think we should give it some consideration.
(I too would like a solution rather sooner than later.)

> `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?

If something like `usr/share/c++/module/<module-name>.json` is easier to
standardize, I've no objections. Then we need to specify what
information build systems need in the JSON file. I think that should be
relatively easy with build system vendors participating in SG15.


Cheers,
Mark