Mathematical software has traditionally been built in the form of "packages" that build on each other. A substantial fraction of these packages is written in C++ and, as a consequence, the interface of a package is described in the form of header files that downstream packages and applications can then #include. C++ has inherited this approach towards exporting interfaces from C, but the approach is clunky, unreliable, and slow. As a consequence, C++20 has introduced a "module" system in which packages explicitly export declarations and code that compilers then store in machine-readable form and that downstream users can "import" -- a system in line with what many other programming languages have used for decades. Herein, I explore how one can convert large mathematical software packages written in C++ to this system, using the deal.II finite element library with its around 800,000 lines of code as an example. I describe an approach that allows providing both header-based and module-based interfaces from the same code base, discuss the challenges one encounters, and how modules actually work in practice in a variety of technical and human metrics. The results show that with a non-trivial, but also not prohibitive effort, the conversion to modules is possible, resulting in a reduction in compile time for the converted library itself; on the other hand, for downstream projects, compile times show no clear trend. I end with thoughts about long-term strategies for converting the entire ecosystem of mathematical software over the coming years or decades.

翻译：数学软件传统上以“软件包”的形式构建，各软件包之间相互依赖。其中相当一部分软件包是用C++编写的，因此软件包的接口通常以头文件形式描述，下游软件包和应用程序可通过`#include`使用。C++从C语言继承了这种接口导出方式，但该方法笨拙、不可靠且效率低下。因此，C++20引入了“模块”系统，软件包可显式导出声明和代码，编译器以机器可读形式存储，下游用户可通过`import`使用——这一系统与许多其他编程语言已沿用数十年的方式一致。本文以包含约80万行代码的deal.II有限元库为例，探讨如何将用C++编写的大型数学软件包迁移至该系统。我描述了一种从同一代码库同时提供基于头文件和基于模块接口的方法，讨论了迁移过程中遇到的挑战，以及模块在多种技术指标和人为指标下的实际表现。结果表明，尽管需要投入可观的努力（但并非不可承受），将软件包迁移至模块是可行的，迁移后库本身的编译时间有所减少；然而对于下游项目，编译时间并未呈现明确趋势。最后，我就未来数年或数十年内将整个数学软件生态系统迁移至模块的长期策略提出思考。