Any volunteers for a first pass? Preferably someone with some experience in this area? (hint hint Boris Kolpackov)
The other person I’m thinking of that will probably have valuable (and strong) opinions on the matter is John Lakos, seeing as he has literally written a book on this kind of topic… though not with modules as a backing technology.
From: email@example.com <firstname.lastname@example.org>
On Behalf Of Titus Winters
Sent: Wednesday, April 11, 2018 9:07 AM
To: WG21 Tooling Study Group SG15 <email@example.com>
Subject: Re: [Tooling] Request for modules recommendations
Yeah, those seem like great questions to be asking. Thanks, Ben.
On Wed, Apr 11, 2018 at 12:58 AM Boris Kolpackov <firstname.lastname@example.org> wrote:
Ben Craig <email@example.com> writes:
> * What granularity should I provide for my modules?
> ** Do I translate headers to modules one-to-one?
> ** Do I just have one big module for my entire library?
> ** Something in between?
> * What file extension(s) should I use for module files?
> * How should we map module names to file names? Just by replacing
> dots with slashes?
> * How should tools find modules?
> I know just enough about modules to ask subtly wrong questions, [...]
No, these are spot on. We had to answer all of these (and some more)
while adding support for modules in build2.
The problem of mapping module names to file names is especially tricky:
1. We don't want it to become tedious like specifying the mapping for
each module explicitly would be.
2. We want decent performance from the build system so parsing each
module interface to find its name is probably not an option.
3. We want the file names to fit the project's overall scheme (some
might want FooBar, others foo_bar, I like foo-bar and you seem
to prefer foo/bar).
Tooling mailing list