我对我的项目做了一个 make distclean 认为它真的会删除所有内容,但它留下了一个 .deps 目录,并留下了我所有的编辑器备份文件。
AutoTools 实现的一般规则是
- 如果
make 创建了它,那么make clean 应该清理它。
- 如果
configure 创建了它,那么make distclean 应该清理它。
- 如果
autoconf、automake 或其他 AutoTools 之一创建它,则 make maintainer-clean 应该清理它。
由于您可以将任意代码注入 configure 和您的 makefile,因此 AutoTools 无法确保普遍遵循该规则,但文档确实建议您遵守它。
您的编辑器备份文件未清理是意料之中的。此类文件超出了目标清理什么的规则范围,AutoTools 不会试图猜测它们在创建或管理中没有作用的文件的重要性是正确和正确的。他们不应该有任何关于如何处理这些文件的内置策略。
但是,如果您希望您的特定项目有这样的政策,那么这在您的控制范围内。您的任何或所有Makefile.am 文件都可以通过添加distclean-local 目标来添加要由make distclean 执行的额外操作。例如,
distclean-local:
rm *~
如何对其他目录进行类似操作的详细信息取决于您的项目的结构。
autom4te.cache 目录及其内容有些不同。这主要由 AutoTools 自己创建和使用 -- autoconf、automake、等。 -- 所以自然不会被make distclean 清理。相反,根据规则,它由make maintainer-clean 清理。不过,这有点模糊,因为在某些情况下,make 会重新运行这些工具。然而,当它这样做时,它是在这些工具的输入(Makefile.am,configure.ac,...)的上下文中被修改的,这是项目维护者活动,而不是项目构建者活动,所以仍然合理将清理职责分配给maintainer-clean。
不过,如果您希望distclean 清理autom4te.cache,则可以采用与编辑器备份文件所述相同的方法,尽管它仅在顶级Makefile.am 中有用。例如,
distclean-local:
rm -rf autom4te.cache
.deps 目录是第三层。它是由make创建的,所以按照规则应该由make clean清理,而由make maintainer-clean清理。这是有道理的,因为依赖信息会增强您的 makefile 并通知构建,并且原则上,它可以通过其他方式生成,而不是作为构建项目的副作用。当目标文件不是时,它当然不应该被清理,因为这可能导致后续构建无法重新生成实际上需要重新构建的二进制文件。但是如果无论如何都需要构建目标文件(因为它们丢失了),那么无论如何都会重新构建依赖信息,所以让make distclean 完成这项工作并没有什么坏处。你可以像其他人一样做到这一点。
最后,清理因make dist 或make distcheck 运行失败而导致的分发目录。准备分发是维护者的活动,尽管这些工件是通过make 工具生成的,但它们不是由默认的make 运行生成的。我会将这些清理责任放在maintainer-clean 上,但我不确定它是否真的能处理它们。您绝对可以按照与其他工件所述相同的方法来获取 distclean 以删除这些工件。但是请注意,
- 您可能需要在这些目录上执行递归
chmod 以在实际删除它们之前授予自己写权限,并且
- 如果您使用 glob 模式来执行此类目标的清理,则应格外小心,因为命名的性质会产生意外匹配您想要保留的文件的特殊风险。
当然,您可以将其中的部分或全部组合起来(通过多行配方组合成一条规则),以将其中一些行为添加到项目的构建系统中。