Common Lisp 编译器要重新编译多少次？

Question

虽然不是所有的 Common Lisp 实现都编译成机器代码，但其中一些实现了，包括 SBCL 和 CCL。

在 C/C++ 中，如果源文件不改变，C/C++ 编译器的二进制输出也不会改变，假设底层系统保持不变。

在 Common Lisp 编译器中，与 C/C++ 不同，编译不受用户直接控制。我的问题是，如果 Lisp 源文件没有改变，在什么情况下 CL 编译器会多次编译代码，为什么？如果可能，一个简单的说明性示例会有所帮助。

Answer 1

我认为这个问题是基于一些误解。编译器不编译文件，这不是用户无法控制的。编译器很容易通过compile 函数获得。编译器在代码上运行，而不是在文件上运行。例如，您可以在 REPL 中键入

CL-USER> (compile nil (list 'lambda (list 'x) (list '+ 'x 'x)))
#<FUNCTION (LAMBDA (X)) {100460E24B}>
NIL
NIL

根本不涉及任何文件。不过还有一个compile-file函数，但是注意它的描述是：

compile-file 转换指定文件的内容 将输入文件转换为与实现相关的二进制数据，这些数据被放置 在 output-file 指定的文件中。

文件的内容被编译。那么那个编译文件可以是loaded。 （您也可以 load 未编译的源文件。）我认为您的问题可能归结为询问在什么情况下 compile-file 会生成具有不同内容的文件。我认为这真的取决于实现，而且它并不是真正可预测的。我不知道您对其他语言的编译器的描述是否必然成立：

在 C/C++ 中，如果源文件不变，则 C/C++ 编译器也不会改变，假设底层系统 保持不变。

如果编译器碰巧在某个数据段的输出中包含时间戳怎么办？然后你每次都会得到不同的二进制输出。确实，一些常见的脚本编译/构建系统（例如，ma​​ke 和类似系统）会根据输入文件在此期间是否发生变化来检查是否可以重用之前的输出。不过，这并没有真正说明 编译器 的作用。

Answer 2

规则几乎相同，但在 Common Lisp 中，将声明与实现分开不是一种做法，因此通常您必须重新编译每个依赖项才能确定。这是动态环境的共同实际结果。

假设存在这样的分离，以下是需要重新编译特定依赖文件的明显示例（显然并非详尽无遗），因为输出可能会有所不同：

• 更改的包定义
• 更改的宏字符或其代码发生更改
• 已更改的宏
• 添加或删除 inline 或 notinline 声明
• 全局类型或函数类型声明的更改
• #.、defvar、defparameter、defconstant、load-time-value、eql 专门人员、make-load-form 生成的代码、defmacro 等中使用的更改函数（例如 setf 扩展程序）。 ..
• Lisp 编译器或基础映像中的更改

我的意思是，您可以看到确定哪些文件需要重新编译并非易事。有时，答案是“所有后续文件”，例如更改"（双引号）宏字符，这可能会影响每个文字字符串，或者编译器以非向后兼容的方式发展。从本质上讲，我们从开始的地方结束：您只能确保完全重新编译，而不是跨编译重用 fasls。有时它比确定需要重新编译的最小文件集更快。

在实践中，您最终会在开发过程中大量编译单个定义（例如使用 Slime），而不是当 fasl 与源文件一样旧或更年轻时重新编译文件。很多时候，您重用来自例如的文件。快点。但对于测试和部署，我建议清除所有 fasls 并重新编译所有内容。

已经努力使用 SBCL 自动化最小依赖项编译，但我认为当您更频繁地更改临时项目时它太慢了（它涉及大量分叉，因此在 Windows 中它要么不可行要么非常慢）。但是，对于很少更改（如果有的话）的基础库，这可能会节省时间。

另一种方法是使用内置的基本库（即您始终加载的那些）制作自定义基本映像。它将节省编译和加载时间。