Subject: [std-proposals] We should use existing scientific research in building C++ modules
From: Askar Safin (safinaskar_at_[hidden])
Date: 2020-05-15 11:44:59
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].
* There is scientific research about building systems: [ALACARTE]. I recommend people working on modules to use it
* [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?
* [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?
* [MAP] and [GENMAP] propose so-called module mapper. I think their solution is too complex. It seems this solution will not fit even in [ALACARTE] framework, and this is very bad sign. Maybe something like Ninja 1.10 solution (see above) will go?
* I recommend learning very elegant solutions suggested by build systems [REDO] and [TUP]
I don't understand how C++ modules work, I just want to connect modules designers with current scientific research (i. e. [ALACARTE]) and other useful links until it is too late.
This letter is sent to std-proposals, to authors of [ALACARTE], [MAP] and [GENMAP] and to one cmake author. I hope my letter is useful enough to bother all these people. If not, I am very sorry.
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups