On Fri, May 15, 2020 at 13:17:24 -0400, Matthew Woehlke wrote:
> On 15/05/2020 12.44, Askar Safin via Std-Proposals wrote:
> > Hi. I want to share some thoughts and links on the problem of
> > building C++20 modules (and Fortran modules). Building modules is
> > hard, see [FORTRAN] and [CONCERNS].
> > [...]
> > * [FORTRAN] (published Oct 2018) says that existing build systems
> > fail to build Fortran modules reliable. In particular, [FORTRAN]
> > blames standard version of Ninja and says that Ninja requires custom
> > patches to build Fortran modules. But Ninja 1.10 (released Jan 2020)
> > seem to solve problem of building Fortran modules using so-called
> > "dynamic dependencies" [NINJA]. Maybe same solution could be used for
> > C++ modules?
>
> That is, indeed, the plan. Incidentally, C++ adding modules was a major
> impetus to finally landing this code in Ninja proper.
>
> BTW, as I understand it, some of this stuff is going to be addressed in
> the forthcoming SG15 TR.

Yes. I have a proof-of-concept for patched CMake, Ninja 1.10, and
patched GCC here[1]. It has scripts for building a Docker image[2] and I
have some published[3] too. Note that this only supports named modules
(no header units) and modules are not exported from a CMake build and
cannot be imported from outside either.

> > * [FORTRAN] recommends using cmake with make back-end for building
> > Fortran modules. And mentions large amount of cmake code, which was
> > added to support Fortran modules. Maybe all this code can be removed
> > due to presence of Ninja feature I talk above?
>
> That sounds like a question for a CMake developer (probably Ben, Brad or
> Kyle), but my guess would be that that code, rather than going away, is
> becoming more generalized to support both Fortran and now also C++.

I think the code in question is the Fortran parser that CMake ships for
figuring out module information. That's unlikely to go anywhere until
Fortran compilers support getting module dependency information from
them.

The Makefiles generator will need basically rewritten to be able to lay
down the code effectively, but that's been overdue anyways.

> > * I recommend learning very elegant solutions suggested by build systems [REDO] and [TUP]
>
> Hmm, I wonder if redo would make an interesting target for CMake? (Based
> on lack of professionalism in the documentation, I have serious
> reservations about tup...)

I would need to look more at redo, but if it can't discover dependencies
of things during the run, it would need work. It looks like it handles
incidental includes just fine (which is what headers are), but not "I
need whatever provides X" and "provides X" needs to be discovered from
other build rules.

I've asked the Tup list how they expect to support modules. I don't see
how it can work without massive rework to support scanning for
dependencies at runtime.

--Ben

[1]https://github.com/mathstuf/cxx-modules-sandbox/
[2]https://github.com/mathstuf/cxx-modules-sandbox/tree/docker
[3]https://hub.docker.com/r/benboeckel/cxx-modules-sandbox/tags