distcc的阶段到底意味着什么？我已经在使用泵模式了吗？在Cygwin中如何使用泵模式？

从我所读到的内容来看，要想在distcc中使用pump模式，需要在

pump

脚本中封装make。但是，我的路径中没有它，我找不到它或包含在for Cygwin中

但是，当我使用distcc编译并使用它来监视哪些主机被联系，以及它们的阶段时，我清楚地看到其中一些主机有时处于预处理阶段。我认为所有的预处理都是在不使用泵模式时在执行make脚本的客户机上完成的。泵模式的整个思想是在远程主机上进行预处理（因此需要相同的包含文件）

这让我感到困惑我的主要问题是：distcc的启动、阻塞、连接、预处理、连接、发送、接收和完成阶段到底意味着什么

作为子问题：我如何在Cygwin中使用distcc的泵模式

distcc的具体阶段是什么 什么意思

好吧，这很尴尬，但我只是在网上浪费了四个小时试图回答这个问题。下一次，我将只提取源代码并查看它。但是，你提出了一个很好的观点：令人惊讶的是，这不是现成的信息

这些是我的猜测（因为我不想承认我浪费了四个小时没有回答这个问题！）：

• 启动-否则可以调用 “初始化/加载”，还没有 准备好第一项任务了吗
• 被阻止-正在等待访问本地 文件或本地处理器，我绊倒了
  在最近的错误修复中，它将“超时”设置为1秒，同时等待 处理器变得可用，我知道它有时会使用零长度的“

  flock

  ”文件进行阻止
• 已连接-流程启动联系人 对于客户端，现在保留为 作业（？），或正在编译作业（？）
• 预处理-正在执行预处理 操作
• Conect-正在与客户握手以进行原子操作，可能是为了保留 （？？）
• 发送-正在发送已编译的对象 文件返回到客户端
• 接收-接收源是否为 已编译，或接收压缩的标题 （如果使用泵模式）
• 完成-否则可以调用 “空闲/可用”

注意：由于谷歌的“泵模式”算法，实际上在客户端（运行

distcc

）和志愿者（运行

distccd

）之间有相当多的“握手”。首先，在泵模式下，所有预期“需要”的头被捆绑、压缩并推送到志愿者（在那里它被解压缩到客户端机器上的本地镜像中）。然而，志愿者和客户之间的一些进一步通信似乎可以根据需要增量传输其他标题，因此可以解释上面列出的“更丰富”的通信阶段/状态

我非常怀疑这一点，因为您没有通过

make

或

scons

包装编译选项来配置它（这是运行Google算法预测绑定和传输到志愿者的头使用情况所必需的），您也找不到“pump”脚本。但是，我无法解释您看到志愿者身上的“

预处理”状态。（您不是指客户机上的“预处理”状态，对吗？这完全可以理解，因为默认情况下，预处理是在客户机上进行的。）

相反，我认为实现使得硬状态机有可能在进入下一个状态之前，通过所有状态，包括“预处理”，即使没有预处理要做。例如，即使它在志愿者端没有进行预处理，distccd也会接收源文件，将其写入磁盘，然后启动编译器。如果您使用的是Cywin，那么这些都不是即时的，尤其是当它是一个大的源文件时（尤其是在包含所有头文件之后）。因此，您可能会看到“预处理”阶段，直到它手动启动编译操作本身的下一个阶段

嘿。。。我没有看到明显的“编译”阶段，因此“预处理”阶段可能包含“编译”或“预处理和编译”（因为这些阶段通常在许多编译器中组合）

对不起，我只是在猜

在Cygwin中如何使用泵模式

我还没试过，但这应该是可能的。显然，
Cygwin
最常见的问题是，当在Cygwin下运行
distcc
时，某些Windows编译器无法处理默认的
TMPDIR
设置。解决方法是在
/etc/profile

常见问题解答可能会提供更多帮助：

Am I already using pump mode?