使用递归依赖聚合构建系统
我最近开始使用跨平台构建系统（按需生成 make 文件、Visual Studio 解决方案/项目等）建立自己的库和项目，并且我遇到了一个可能已经解决的问题。
我遇到的问题是：当应用程序的依赖项也具有依赖项时，正在链接的应用程序必须链接该依赖项及其所有子依赖项。这以递归方式进行，例如
（为了论证，我们假设我们只处理静态库。）
- TopLevelApp.exe
- 依赖_A
- dependency_A-1
- dependency_A-2
- 依赖_B
- 依赖_B-1
- 依赖_B-2
- 依赖_A
因此，在这个示例中，TopLevelApp 需要链接 dependency_A、dependency_A-1、dependency_A-2 等，对于 B 也是如此。我认为在目标应用程序中手动记住所有这些的责任是相当次优。还有一个问题是要确保所有目标都使用相同版本的依赖项（假设某些目标依赖于相同的东西，例如 boost）。
现在需要链接所有库，并且没有办法绕过它。我正在寻找的是一个为您管理此内容的构建系统。因此，您所要做的就是指定您所依赖的东西，并且该库的适当依赖项将被自动拉入。
我一直在研究的构建系统是 premake premake4 ，它不能处理这个问题（据我所知）。有谁知道可以处理这个问题的构建系统？如果没有那为什么不呢？
I recently began setting up my own library and projects using a cross platform build system (generates make files, visual studio solutions/projects etc on demand) and I have run into a problem that has likely been solved already.
The issue that I have run into is this: When an application has a dependency that also has dependencies then the application being linked must link the dependency and also all of its sub-dependencies. This proceeds in a recursive fashion e.g.
(For arguments sake lets assume that we are dealing exclusively with static libraries.)
- TopLevelApp.exe
- dependency_A
- dependency_A-1
- dependency_A-2
- dependency_B
- dependency_B-1
- dependency_B-2
- dependency_A
So in this example TopLevelApp will need to link dependency_A, dependency_A-1, dependency_A-2 etc and the same for B. I think the responsibility of remembering all of these manually in the target application is pretty sub optimal. There is also the issue of ensuring the same version of the dependency is used across all targets (assuming that some targets depend on the same things, e.g. boost).
Now linking all of the libraries is required and there is no way of getting around it. What I am looking for is a build system that manages this for you. So all you have to do is specify that you depend on something and the appropriate dependencies of that library will be pulled in automatically.
The build system I have been looking at is premake premake4 which doesn't handle this (as far as I can determine). Does anyone know of a build system that does handle this? and if there isn't then why not?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
处理此问题的典型方法是让您所依赖的库告诉您它需要什么以及它链接的版本。一种方法是通过 pkg-config。例如，如果您调用 pkg-config name_of_package --cflags，它将打印出必要的标志，其中应包括添加间接依赖项标头所需的标志。类似地， pkg-config name_of_package --ldflags 将打印必要的链接器标志，其中包括该特定库及其依赖项。至于构建系统，我的建议是使用 CMake。在 CMake 中，通过调用 FIND_PACKAGE(name_of_package) 来找到依赖项，如果找到了包，则该调用又将变量 name_of_package_FOUND 定义为 1，并且如果找到了，则将 name_of_package_LIBRARIES 和 name_of_package_INCLUDE_DIRS 定义到库和头文件路径对于该包及其依赖项的库和标头。也就是说，FIND_PACKAGE 机制通过第三方编写的可插入模块来工作，因此虽然系统应该设置 _LIBRARIES 和 _INCLUDE_DIRS 变量，以便递归地包含依赖项的依赖项，但并不是所有模块都能正确执行上次我检查的操作。
The typical way that this is handled is by having the library on which you depend tell you what it, in turn, requires and what versions it has linked against. One way of doing this is via pkg-config. For example, if you invoke pkg-config name_of_package --cflags, it will print out the necessary flags that should include flags needed to add headers of indirect dependencies. Similarly, pkg-config name_of_package --ldflags would print the necessary linker flags that include that particular library as well as its dependencies. As for build system, my recommendation would be to use CMake. In CMake, dependencies are found via an invocation of FIND_PACKAGE(name_of_package), which in turn defines the variable name_of_package_FOUND as 1 if the package was found, and also -- if it was found -- defines name_of_package_LIBRARIES and name_of_package_INCLUDE_DIRS to the libraries and header paths for that package as well as to the libraries and headers of its dependencies. That said, the FIND_PACKAGE mechanism works via pluggable modules written by third parties, and so while the system is supposed to set the _LIBRARIES and _INCLUDE_DIRS variables such that dependencies of dependencies are included recursively, not all of the modules do this correctly last I checked.