第三方库应该放在哪里？
我为一个具有许多依赖项的规模相当的 C++ 项目做出了贡献。问题是，该项目包含其所有依赖项的源代码（例如 pcre、zlib 等）。我想将项目精简为与程序本身相关的内容。是否有一些相对标准的方法来编译这些库并将它们放在某个地方，并且它们的头文件也可以轻松访问？
无论如何，我使用的是 Windows 7，并且使用 VS2005 进行开发。我也是一个在 Windows 上从事大型 C++ 项目的完全菜鸟。我从来没有真正需要走出标准库和 win32。
I contribute to a decent-sized C++ project with a number of dependencies. The problem is, the project contains the source of all of its dependencies (e.g. pcre, zlib, etc.). I want to trim the project down to just what's relevant to the program itself. Is there some relatively standard way to compile these libraries and put them somewhere, and have their header files also easily accessible?
For what it's worth, I'm using Windows 7, and I'm developing using VS2005. I'm also a complete noob with working on large C++ projects on Windows; I've never really needed to step outside the standard library and win32.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我们在工作场所使用的结构是有一个“外部”文件夹，其中包含一个“包含”和一个“库”文件夹，用于存放标题和外部库。但是，由于我们也使用 VS，因此我们尝试尽可能地使用其“依赖项”功能，从而消除对链接器的手动输入。这意味着只有不在同一解决方案下的项目才会进入“外部”文件夹。此外，由于我们有一些特定于某些项目的第三方库，因此我们在项目文件夹内为这些包含和库创建文件夹。它是这样的：
我无法判断这是否是最好的结构，但一切都在源代码控制之下，我们可以通过构建解决方案来进行夜间构建，并且通过构建单个项目来进行开发。
A structure that we use on my workplace is having one "External" folder that contains an "Include" and a "Lib" folder for the headers and external Libs. However, as we also use VS, we try to use its "Dependencies" feature as most as possible, removing manual inputs to the linker. That means only projects that are not under the same solution goes to the "External" folder. Also, as we have some third-party libraries specific to some projects, we create folders inside the project folder for these includes and libs. This is how it gets:
I can't tell if this is the best structure ever, but everything is under source control, we can do night builds just by building the solution, and development goes by building single projects.
你的陈述中有一个谬误：“我想将项目精简到只与项目本身相关。”
相信我，依赖关系与程序极其相关。如果您在源代码管理中没有这些，那么在引入新的团队成员或切换到新的工作站时，您将遇到无穷无尽的问题。
即使编译“不相关”的库，这些编译的库也应该进入您的源存储库。
There's a fallacy in your statement: "I want to trim the project down to just what's relevant to the program itself."
Believe me, the dependencies are extremely relevant to the program. If you don't have these in source control then you will encounter no end of problems when introducing new team members or when switching to a new workstation.
Even if compile the "non-relevant" libraries, these compiled libraries should go into your source repository.
我见过一些团体执行以下操作：
每个 exe 或库的项目都存在于 exe/library 目录中。
解决方案存在于团队认为有益的任何地方，并且二进制文件通常是链接的，而不是包含在子解决方案中的项目。只有完整的构建才能保证在新入伍时不会中断。
买者自负...
I've seen groups do the following:
Projects existed for each exe or library, in the directory with the exe/library.
Solutions existed wherever the teams felt it would be beneficial, and binaries were often linked, rather than their projects included in the sub-solutions. Only a full build was guaranteed not to break on a fresh enlistment.
Caveat emptor...