在这个makefile中，为什么总是重新制作目标“bunzip2/data2.tar”的先决条件？答案

【问题标题】：In this makefile, why is the prerequisite for the target "bunzip2/data2.tar" always being remade?在这个makefile中，为什么总是重新制作目标“bunzip2/data2.tar”的先决条件？
【发布时间】：2015-05-14 08:20:47
【问题描述】：

尽管先决条件是最新的，但我有一个总是重新运行规则的 make 文件：

data.tar.bz2: data.tar
    bzip2 --keep data.tar

# The following rule always runs the rule for its prerequisite
# even if it is up-to-date. Note that it doesn't matter whether
# the bunzip2 directory exists or not. I suppose is has something
# to do with the dir/file naming of the rule but I haven't been
# able to decipher why.
bunzip2/data2.tar: data.tar.bz2
    mkdir bunzip2 && cd bunzip2 && bzip2 -ckd ../data.tar.bz2 > data2.tar && cd ..

.PHONY: clean
clean:
    rm -f data.tar.bz2
    rm -Rf bunzip2

任何想法表示赞赏。

【问题讨论】：

标签： makefile compression bzip2 xz

【解决方案1】：

示例中缺少某些内容 - 但分析过程是相同的，无论如何：您可以使用 make 的调试功能来查看它使用的规则，例如，

make -d

【讨论】：

【解决方案2】：

在文件上设置时间戳的标准 POSIX 系统调用不支持亚秒级精度。为了让这些工具在文件上设置特定时间（他们试图这样做以使压缩文件与原始文件具有相同的时间戳）并保持原始准确性，他们需要使用不同的系统调用；显然他们没有这样做。

要解决这个问题，您可以像这样更改您的规则：

data.tar.bz2: data.tar
        bzip2 --keep data.tar && touch $@

以便将目标的时间戳设置为“现在”。

ETA 用于设置文件修改时间的传统系统调用是utime()，它只接受以一秒为增量的时间戳。较新版本的 POSIX 规范引入了utimensat()，它允许纳秒时间戳设置。还有utimes()，它允许微秒级精度，但长期以来一直被认为是“遗留”。

如果当前最新版本的bzip2 中存在这种行为，我会认为这是一个值得向他们报告错误的错误。

【讨论】：

是的。发现问题后，触摸是我的解决方法。感谢您提及 POSIX。
我正在运行 Debian Wheezy。值得一提的是，我有 bzip2 v1.0.6、lzip v1.13（带有 lunzip v1.1）和 unxz 5.1.0alpha。好像 bzip2 v1.0.6（从 2010 年开始！）是 the current release 而 lzip (v1.16) 和 xz (v5.2.1) 不是。
我没有定义新标签的声誉，但如果您可以在这个问题中添加“lzip”作为标签，那将是有益的。

【解决方案3】：

我想我知道这里发生了什么。

使用@Thomas Dickey 建议尝试make -d，它表示文件data.tar.bz2 比data.tar 本身更新。这似乎很愚蠢，因为前者是从后者创建的。但是使用 ls --full-time 显示 bzip2 存档似乎使用了源文件的时间戳，但它在第二位之后也截断了它。在我的例子中，时间戳2015-03-12 09:32:02.452091888 被截断为2015-03-12 09:32:02.000000000，这使它看起来比源更新。（截断我的意思是2015-03-12 13:10:29.681793152 转到2015-03-12 13:10:29.000000000...即使在这种情况下也不会四舍五入）似乎 bzip 需要提高其时间戳的准确性。

lunzip 似乎也截断了时间戳，unxz 保留了原始时间戳，而gzip 使用了当前时间。换句话说，在使用压缩工具时要小心你的 makefile，因为它们处理事情的方式不同。

【讨论】：