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