Scon如何计算生成签名？

Question

我将一个项目的不同版本保存在不同的目录中。(这在这个项目中是有意义的。可悲的是)由于版本之间的差异很小，我希望在第一个版本之后，通过对所有构建使用一个公共缓存目录来加速所有构建。

不幸的是，我不得不意识到，当在不同目录中从相同的源文件构建对象文件时，SCons 2.3.3将结果存储在缓存中的不同位置。(我猜想，这个位置等于构建签名。)对每个目录都重新编译相同的源代码。那么，为什么SCons决定不同的构建签名，尽管

• 编译命令是相同的，
• 源和包含文件是相同的(预处理阶段( gcc -E ...)的相同输出)
• 我用的是“MD5-时间戳”

甚至结果的对象文件也是相同的！

对于一个简单的示例(来自helloworld文档的SCons )，可以重用缓存工作。虽然在我正在做的大项目中，它没有。也许"SCons构建环境“会影响构建签名，即使它对编译命令没有任何影响？

除了--cache-debug=-，还有什么调试选项可以帮助您吗？SCons的哪种方法决定构建签名？

文件夹看起来有点像这样：

<basedir1>/
       SConstruct
       src/something.cpp …
       include/header.hpp …
<basedir2>/
       SConstruct
       src/something.cpp …
       include/header.hpp …
/SharedCache/
       0/ 1/ 2/ … F/

我查看了basedir1和basedir2中的项目，并在它们中调用了scons --build-cache-dir=/SharedCache。(编辑：--build-cache-dir是一个自定义选项，在该项目的SConstruct文件中实现。它映射到env.CacheDir('/SharedCache')。

EDIT2:在我意识到这个问题之前，我做了一些测试来评估使用--cache-implicit或SCons 2.4.0的效果。

Answer 1

这是文件get_cachedir_bsig()中的方法src/engine/SCons/Node/FS.py的代码

def get_cachedir_bsig(self):
    """
    Return the signature for a cached file, including
    its children.

    It adds the path of the cached file to the cache signature,
    because multiple targets built by the same action will all
    have the same build signature, and we have to differentiate
    them somehow.
    """
    try:
        return self.cachesig
    except AttributeError:
        pass

    # Collect signatures for all children
    children = self.children()
    sigs = [n.get_cachedir_csig() for n in children]
    # Append this node's signature...
    sigs.append(self.get_contents_sig())
    # ...and it's path
    sigs.append(self.get_internal_path())
    # Merge this all into a single signature
    result = self.cachesig = SCons.Util.MD5collect(sigs)
    return result

它展示了缓存文件的路径是如何包含到“缓存构建签名”中的，这说明了您所看到的行为。为了完整起见，下面还有来自同一个get_cachedir_csig()文件的FS.py方法的代码：

def get_cachedir_csig(self):
    """
    Fetch a Node's content signature for purposes of computing
    another Node's cachesig.

    This is a wrapper around the normal get_csig() method that handles
    the somewhat obscure case of using CacheDir with the -n option.
    Any files that don't exist would normally be "built" by fetching
    them from the cache, but the normal get_csig() method will try
    to open up the local file, which doesn't exist because the -n
    option meant we didn't actually pull the file from cachedir.
    But since the file *does* actually exist in the cachedir, we
    can use its contents for the csig.
    """
    try:
        return self.cachedir_csig
    except AttributeError:
        pass

    cachedir, cachefile = self.get_build_env().get_CacheDir().cachepath(self)
    if not self.exists() and cachefile and os.path.exists(cachefile):
        self.cachedir_csig = SCons.Util.MD5filesignature(cachefile, \
            SCons.Node.FS.File.md5_chunksize * 1024)
    else:
        self.cachedir_csig = self.get_csig()
    return self.cachedir_csig

其中，子程序的缓存路径被散列为最终构建签名。

编辑:如上面所计算的“缓存生成签名”，然后用于构建“缓存路径”。像这样，所有文件/目标都可以映射到一个唯一的“缓存路径”，通过该路径可以在缓存中引用和找到它们。正如上面的注释所解释的，每个文件的相对路径(从您的SConstruct的顶级文件夹开始)是这个“缓存路径”的一部分。因此，如果您在不同的目录中有相同的源/目标(foo.c->foo.obj)，它们将有不同的“缓存路径”，并且彼此独立构建。

如果您确实希望在不同项目之间共享源，请注意CacheDir功能是如何更适合在不同开发人员之间共享相同资源的，您可能想看看Repository()方法。让我们将另一个源树安装到当前的项目中.