我为一个包含许多子模块的项目维护一个“主”makefile，每个子模块都有自己的自动工具结构。该项目在多种配置中进行了测试（例如，针对不同版本的后端构建），并且可以使用 NFS 上的相同主目录或交叉编译器在不同平台/架构上构建。所有这些都是通过获取当前源签出（git repo 克隆）工作区、将源“克隆（*）”到当前构建设置的单独目录并configureing/ autogening 该源克隆（因此不会污染原始签出）来处理的，以及最后在自动工具的支持下，在树外构建它。
“(*)克隆”部分以多种方式实现，例如cp/tar将原始工作空间复制到“源克隆”，或者通过在克隆中创建目录结构，并填充主工作空间中原始文件的相对符号链接。这里有龙:)
由自然文件填充的源克隆是自给自足的，并且可以很好地传递 automake 作业，特别是dist( 和distcheck) 作业 - 与“符号链接克隆”不同，“符号链接克隆”make dist显然“按原样”打包相对符号链接，因此在解压后它们指向任何地方有意义的。
符号链接的好处是开发人员可以编辑工作区中的文件并一次性重建所有平台，而无需将它们提交到 git 等 - 加快开发迭代周期（至少只要不添加新文件 - 只需重新-“制作”已编辑的现有内容）。与多次复制相同文件相比，它的存储和时间开销也大大减少。
所以问题是：是否可以“制作 dist”一个由原始源的相对符号链接填充的目录？也许有一些“dist hook”或其他方法来覆盖 tarball 的制作方式？ （如果该dist过程通过取消引用源目录符号链接在其专用子目录中创建真实文件，这是可以接受的）
或者这根本不可行，我们不能鱼与熊掌兼得？ :)
（作为参考，有问题的“主”Makefile 位于https://github.com/42ity/FTY/）