[Dani]
> 1) if a library is split into type-based subdirectories (like e.g.
> 'inc', 'include' for header files and 'src', 'source' for source files)
> then I create a new subdirectory 'module' and place *all* additional
> module TUs with BMI outputs (like *.ixx for the PMIF, interface
> partitions, and internal partitions) in there. I still haven't made my
> mind up yet where to eventually place module implementation TUs (*.cpp)
> (if any): either into the source file subdirectory or into the module
> subdirectory.

+1.

> 2) if a library is *not* split into type-based subdirectories then the
> additional module TUs go side-by-side with the headers that contain the
> library interface

I tried this a few times. I've found that when the target is an executable, then it works well. But, when it is a library, it isn't always clear what is going to be "installed" without looking into the build script, which most of us don't generally want to do - to be fair, most developers don't want to be build experts ("build scripts are someone else's problem"). Maybe it is still just old thinking, but I think having a way to quickly get the lay of the land of what is installed and what is needed only for the build phase is important.

> 3) composed libraries or federations like Boost, Qt, ... is something
> that I haven't gone into yet and need more experiments

I suspect this one is more of the realm of packaging than organization of a single project.

-- Gaby

-----Original Message-----
From: SG15 <sg15-bounces_at_[hidden]> On Behalf Of Daniela Engert via SG15
Sent: Wednesday, July 5, 2023 10:55 PM
To: sg15_at_[hidden]
Cc: Daniela Engert <dani_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

Am 02.07.2023 um 17:41 schrieb Mark de Wever via SG15:
> 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?
>
> The things I would like to discuss are:
> - Are we happy with the proposed locations on non-Windows systems?
> - What would be a good location on Windows?
> - What information do build system vendors need to turn the sources into
> BMI files and how is this information provided.
>
After a long phase of experiments with modularizing existing libraries I
came to this procedure:

1) if a library is split into type-based subdirectories (like e.g.
'inc', 'include' for header files and 'src', 'source' for source files)
then I create a new subdirectory 'module' and place *all* additional
module TUs with BMI outputs (like *.ixx for the PMIF, interface
partitions, and internal partitions) in there. I still haven't made my
mind up yet where to eventually place module implementation TUs (*.cpp)
(if any): either into the source file subdirectory or into the module
subdirectory.

2) if a library is *not* split into type-based subdirectories then the
additional module TUs go side-by-side with the headers that contain the
library interface

3) composed libraries or federations like Boost, Qt, ... is something
that I haven't gone into yet and need more experiments

Thanks
   Dani

_______________________________________________
SG15 mailing list
SG15_at_[hidden]
https://lists.isocpp.org/mailman/listinfo.cgi/sg15