使用Nix封装CentOS5工具链依赖项

Question

我们目前正在调查Nix是否是一个适合我们打包第三方库的工具，以及我们构建软件所需的工具。免责声明:我刚刚了解到Nix，并仍然试图把所有的片段放在一起。

我们的产品需要与CentOS5系统兼容。这就是为什么我们在CentOS5 Docker容器中构建我们的软件的原因，其中有一个定制的GCC，还有很多其他的第三方工具和库都是从源代码构建的。

目前，我们有一个大型Makefile来构建所有这些依赖项，并使用CI作业来构建依赖项。每当其中一个依赖项发生变化，或者对Makefile做了一些更改时，我们就重新构建所有需要很长时间的依赖关系。

我们没有改进Makefile，而是研究更容易维护的更简单的解决方案。我认为Nix可以通过翻译Makefile来分离派生项，并根据每个派生指定正确的依赖项来帮助我们解决这个问题。Nix会是这个用例的合适工具吗？我看到的主要问题是Nix使用一个现代的glibc库作为基派生，这是我们无法依赖的。我们是否需要构建一个定制的glibc版本，或者我们是否可以依赖于主机系统( CentOS5 1)上安装的glibc？

Answer 1

这看起来像是Nix可以帮助您的场景。

我们的产品需要与CentOS5系统兼容。

由Nix (通过Nixpkgs)构建的二进制文件和库不链接到系统库。实际上，这类似于静态链接，但通过不同的方法实现，例如rpath和包装脚本。这将使您的产品ABI与任何发行版兼容，除非您的程序明确要求某些操作系统特性，而不是普通库。例如，如果您的程序依赖于GPU驱动程序，这可能仍然是一个挑战。

GCC的定制建筑

Nixpkgs可以用你的定制GCC来构建所有的软件包或者仅仅是一个选择。

每个派生指定正确的依赖项。

Nix是这个任务的完美人选。我建议在启用沙箱功能的情况下进行构建。如果不运行NixOS，则应该将其安装在多用户模式中并启用沙箱。

我看到的主要问题是Nix使用一个现代的glibc库作为基派生，这是我们无法依赖的。

当使用Nix构建时，您的产品将忽略系统glibc。提供自己的glibc是可行的，但我不认为您真的需要它，因为您正在从源代码构建所有东西，并且与主机系统的兼容性不是一个问题。

或者，我们是否可以依赖于主机系统( CentOS5系统)上安装的glibc？

出于必要，这是在Mac系统上采取的方法。这样做被认为是后退一步；您需要一个很好的理由来这样做。

Nix会是这个用例的合适工具吗？

你应该试试。Nix至少可以为您提供以下保证：

• 指定所有依赖项。
• 并行生成的导子也同样正确。
• 每个构建都是一个干净的构建，即使在重用早期构建的结果时也是如此。
• 可复制性:如果它建立在今天，它就会产生明天，你可以明天修改它。
• 完全依赖关系:安装时不会遗漏任何依赖项。

祝你好运，并毫不犹豫地问一个问题。软件通常不喜欢被强迫做出正确的行为。

并使用CI作业

完全披露:我正在为Nix做一个CI服务。