我们目前正在调查Nix是否可以作为适合我们打包第三方库和构建软件所需工具的工具。免责声明：我刚刚了解了Nix，仍然尝试将所有内容放在一起。
我们的产品需要与CentOS5系统兼容。这就是为什么我们在CentOS5 Docker容器中构建软件的原因，该容器具有自定义构建的GCC，以及许多其他所有第三方工具和库都是从源代码构建的。
当前，我们有一个大的Makefile来构建所有这些依赖关系，并使用CI作业来构建依赖关系。每次其中一个依赖项发生更改或对Makefile进行一些更改时，我们都会重建所有花费很长时间的依赖项。
我们正在研究更易于维护的更简单的解决方案，而不是改进Makefile。我认为Nix可以通过将Makefile转换为每个派生指定正确的依赖关系的派生文件来帮助我们解决此问题。 Nix是适合此用例的工具吗？我看到的主要问题是Nix使用现代glibc库作为基础派生，我们不能依赖它。我们是否需要构建一个自定义的glibc版本，还是可以某种方式依赖于主机系统（CentOS5）上安装的glibc？
答案 0 :(得分：2)
这似乎是Nix可以帮助您的情况。
我们的产品必须与CentOS5系统兼容ABI。
Nix（通过Nixpkgs）构建的二进制文件和库不链接到系统库。实际上，这类似于静态链接，但通过不同的方式（例如rpath和包装器脚本）来实现。这将使您的产品ABI与任何发行版兼容，除非您的程序明确要求除常规库以外的某些操作系统功能。例如，如果您的程序依赖于GPU驱动程序，那可能仍然是一个挑战。
带有定制的GCC
Nixpkgs使您可以使用自定义GCC构建所有软件包或仅选择其中一个。
每个派生指定正确的依赖项。
Nix非常适合此任务。我建议在启用沙箱功能的情况下进行构建。如果您没有运行NixOS，则应将其安装在multi-user mode中并启用沙箱功能。
我看到的主要问题是Nix使用现代glibc库作为基础派生类，而我们不能依靠它。
使用Nix构建时，您的产品将忽略系统glibc。提供自己的glibc是可行的，但我认为您并不是真的需要它，因为您要从源代码构建所有内容，并且与主机系统的兼容性不是问题。
还是我们可以以某种方式依赖于主机系统（CentOS5）上安装的glibc？
这是Mac OS X系统上不必要的方法。这样做将被视为退后一步；您将需要一个充分的理由来做到这一点。
Nix是否适合该用例？
您应该尝试一下。 Nix至少可以为您提供以下保证：
祝您好运，请随时提出问题。软件通常不喜欢被强制采取适当的行为。
并使用CI作业
全部披露：我正在为Nix开发CI服务。