我将尝试重新组织我的小组构建一组大型应用程序的方式，这些应用程序共享大约 90% 的源文件。目前，这些应用程序的构建没有涉及任何库，除了不受我们控制的外部链接库。应用程序使用相同的公共源文件（我们没有维护相同 .h/.cpp 文件的 5 个版本），但这些没有内置到任何公共库中。因此，目前，每次我们打算发布一个版本时，我们都在为每个应用程序一遍又一遍地构建相同的代码付出代价。对我来说，这听起来像是使用库来捕获共享代码并减少构建时间的主要候选者。我没有使用 DLL 的选项，所以方法是使用静态库。
我想知道您对如何完成这项任务有什么建议。我在创建/组织静态库方面的经验有限，所以即使是对组织/陷阱的基本建议也是受欢迎的。也许甚至是一本好书推荐？
通过查找每个应用程序共有的文件的整个子集，我做了一个简短的练习。作为概念证明，我将这些文件放在一个“Common Monster”静态库中。使用这个单一的静态库构建完整的应用程序肯定会缩短所有应用程序的构建时间，但我应该把它留在这里吗？这种形式的库的目的不是很集中，似乎是对模块化的懒惰尝试。这些应用程序正在持续开发中，我担心这种设置会进一步导致问题。
在这方面很难给出一般的指导方针——你如何构建库很大程度上取决于你如何使用它们。也许如果我描述我自己的代码库，这可能会有所帮助：
一个包含代码的通用库，我希望所有应用程序至少有 50/50 的机会需要使用它。这包括字符串实用程序、正则表达式、表达式评估、XML 解析和 ODBC 支持。可以想象，这应该分开一点，但它使在 FOSS 项目中分发我的代码更容易保持它的整体性。
一个支持多线程的库，提供线程、互斥体、信号量等的包装器。
一种通过其本机接口支持 SQLite，而不是通过 ODBC。
围绕 Mongoose C Web 服务器的 C++ Web 服务器包装器。
通用库用于我编写的所有内容，其他内容则用于更专业的情况。每个库的头文件都保存在单独的目录中，库二进制文件本身也是如此（尽管它们可能应该位于单个 lib 目录中）。
确保您的库的依赖关系形成无环有向图（树）。虽然这不一定是静态库的问题（事实上我不确定），但如果您决定切换到 dll，这将是一个问题。根据您的情况，这可能需要重新设计界面。
我注意到的另一件事（肯定在 MSVC 上），如果构建速度是一个重要问题，您可能会考虑：DLL 链接比静态库快得多。我认为这是因为不必将它们复制到新的可执行文件中，也无需搜索消除未使用的代码。即使它不是生产的选项，你也可以在开发时使用这个技巧。
我也有使用 CMake 创建解决方案文件的习惯，因为概览整个构建过程比单击 GUI 中无穷无尽的选项列表更容易。是否要走这条路由您决定。