问题标签 [build-dependencies]

我需要git在 slackware 14 上安装 (v 2.0)。我在安装过程中遇到错误

在源根目录中运行：

继续编译缺少什么？

我正在构建一个需要/usr/bin/rpmbuild安装的规范文件。在 Opensuse13.1 下，这非常简单：我只需在我的规范文件中添加这一行：

这在 Opensuse13.1 上运行良好

然而，当我尝试在 opensuse12.1 上构建和安装这个包时；这不起作用，因为二进制文件/usr/bin/rpmbuild是由 package 提供的，rpm而不是由 package提供的rpm-build。

我该如何解决这个问题？我没有找到他们都提供的虚拟包。请注意，该软件包rpm也存在于 opensuse13.1 上，这rpm-build取决于它。

上下文：我有一个通过网络传输可执行文件的程序。这个可执行文件太大了，所以我ldd -u bigFoo.so在其关联的共享对象上运行。这表明我有大量未使用的共享对象文件占用了一个演出。

问题：给定一段 C++ 源代码foo.cc，它被编译并链接到bigFoo.so中，并且unused.so（由 显示ldd -u）链接到bigFoo.so中，是否有脚本或 shell 命令序列可以快速确定foo.cc导致链接中的调用unused.so？

我正在尝试为 TFS 服务器计划构建定义，并且遇到了一个问题/问题，我想在继续之前得到澄清。

这是我们项目设置的简化版本，抱歉我在这台机器上没有 UML 工具：）

我想要完成的是正确的构建定义，以便：

1. 如果解决方案 1 有签入，则构建解决方案 1 及其依赖项目 Dependency 项目。
2. 如果解决方案 2 有签入，则构建解决方案 2 及其依赖项目 Dependency 项目。
3. 如果 Dependency Project 有签入，则构建解决方案 1 和解决方案 2（带有 Dependency 项目）
4. 如果完成涉及所有 3 个项目的单次签入（例如），则仅构建解决方案 1 和 2一次

我可能会使用门控签入来防止在构建中断时提交源代码控制。

已经有一段时间了，但我相信当时如果我有 3 个构建定义：

• 监控解决方案 1 文件夹 - 构建解决方案 1
• 监控解决方案 2 文件夹 - 构建解决方案 2
• 监控依赖解决方案文件夹 - 构建解决方案 1 和解决方案 2

这在大多数情况下都有效，但是如果在解决方案 1 和依赖解决方案 IIRC 上都发生了一次签入，则解决方案 1 将被构建两次。

虽然这是一个不便，我不必弄清楚，但很高兴知道如何以正确的方式做到这一点。

在 liferay-plugin-package.properties 中有 Portal Dependency 部分，我可以在其中将 jar 添加到 portlet。

我想添加 gson-2.2.4 和 jersey-bundle 但这些 jar 不在列表中。我想将这个 jars 添加到我的项目中，可以使用 Ivy。我的目标是使用 maven 样式，因此编写依赖项并 ivy 下载 jar。我试过添加

进入 ivy.xml 但没有成功。

我们有一个包含许多不同解决方案文件的项目，然后每个解决方案都有许多项目。问题是需要为某些解决方案构建项目。每个开发人员都必须经历打开大型解决方案（包含许多项目的解决方案）的痛苦。问题是这些解决方案并不总是构建，因为必须遵循特定的构建顺序。

我的问题是，有没有办法识别给定目录中每个项目的依赖关系，然后构建这些项目。比如找到所有对我们拥有的其他项目没有任何依赖关系的项目文件。所以先构建这样的项目，然后再构建已经构建了依赖项的项目。

我正在考虑使用 F# 或 Fake 来执行此操作，但我不确定从哪里开始，或者是否可能。

我真的很感激一个例子或我可以获得帮助的链接的答案。

问候，

纳西尔

有没有办法测试在编译具有多个作业的项目时出现的缺失依赖项（-jN where N > 1）？

我经常遇到包，主要是开源包，只要我使用 -j1 或 -jN，构建过程就可以正常工作，其中 N 是相对较低的值，例如 4 或 8，但如果我使用更高的值，例如 48，则有点不常见，由于缺少依赖项而开始失败。

我尝试为自己构建一个 bash 脚本，该脚本将在给定目标的情况下找出所有依赖项，并尝试使用 -j1 显式构建每个依赖项，以验证没有一个依赖项本身缺少依赖项。它似乎适用于小型/中型软件包，但在更重要的软件包上失败，例如 uClibc。

我在这里分享我的脚本，因为有些人可能会更好地理解我通过阅读代码的意思。我也希望存在更强大的解决方案并可以共享回来。

我已经看到了(,${project.version}]maven 依赖项的 version 元素中的值。这些括号和逗号是否意味着任何特殊的东西，使它不同于 just ${project.version}？

我有以下目录结构和库依赖项：

每个目录都包含一个CMakeLists.txt用于生成自己的库的文件。我正在使用源外构建策略。

为了说 lib-b 依赖于 lib-a，我根据官方 CMake 教程add_subdirectory(../lib-a lib-a)所教的内容，将命令放入。通过这种方式，我获得了一个子目录是在../lib-b/CMakeLists.txtlib-a./lib-b/build dir

这不是我想要的行为。我想获得的是 CMake 在生成 lib-b 时引用 lib-a，如果尚未生成 lib-a，CMake 应该使用 CMakeLists.txt 在 ./lib-a/build 内部生成它lib-a（在处理依赖项时的行为类似于 make 工具的行为）。

我还想补充一点，在我的示例中我没有使用根 CMakeLists.txt，但我想要的是 lib-b/CMakeLists.txt 声明对 lib-a 的依赖，从而使 lib-a如果尚未编译，则使用其自己的 lib-a/CMakeLists.txt 进行编译。

这是目录结构及其内容：

lib-b/main.cpp还包含test.hppof lib-a，因为它使用了 lib-a 的功能。这应该在规范中加以考虑lib-b/CMakeLists.txt。

lib-a/CMakeLists.txt和lib-b/CMakeLists.txt文件这两个的内容应该是什么？

有什么方法可以强制自制软件仅安装其所有公式，即没有系统范围的副作用？brew unlink <name>是否可以简单地通过在每个公式之后运行来完成类似的事情？

我问这个的原因是我想要二次安装自制软件，它就像一种安装程序，用于难以构建的科学程序的依赖项，编译和安装这些依赖项在一定程度上与我系统的其余部分。