为调试 emacs ，我有两个分别编译 release 和 debug 版本的构建目录，且不同于 emacs 源码目录；但每次编译 release 版本后再编译 debug 版本，编译（似）会失败，只能先编译一遍 release 版本，make extraclean， 再编译一遍 debug 版本。
问：release 和 debug 能否并存？在只有一份 emacs 源码的前提——即不允许分别为 release 和 debug 构建复制两份源码目录——下。
观察：emacs 构建时（似）会在源码目录下编译 .el 文件并输出在源码目录下。推测：某些编译产物输出到源码目录，致使 debug 与 release 混用。衍生疑问：有无方法使得 .el 的编译输出输出到 build 目录下？emacs 的 release 与 debug 版本编译得到的 .elc 能否混合使用？
能.
好的，谢谢。那我再排查下，看是否是其他问题。
粗看了下，这个似乎和如何使多份 emacs 配置（.init.el）共存有关，但和 emacs 构建无关？
哦，我以为你是要多个配置…没想到是多个不同版本的 emacs，而且是要 build。
我在 reddit 上看到一个人的配置，他自己就是喜欢 build 多个 emacs 的，你可以参考看看：
好的，我参考参考，顺便看下 emacs 的构建。
倒不是喜欢 build ，只是有 gdb emacs 的需求。（这需求应该不算特别罕见，所以想来论坛问问）。
有种被人强掰的感觉… 你只是要 build 多个 emacs 对吧？
是的，具体来说是 build 一个 release ，一个 debug。但我想让这两个 build 依赖同一个源码目录——物理意义上只有一个 emacs 源码文件夹，我不想为每个 build 复制一份 emacs 源码。
我现在的环境配置是：
# 源码目录，autogen.sh -> configure
~/emacs
# release 版本，~/emacs/configure，在其中 make 各种 target。
~/emacs-build-release
# debug 版本，~/emacs/configure 带 -g 及其他调试用的编译选项，
# 在其中 make 各种 target。
~/emacs-build-debug
我会在 ~/emacs-build-debug/src 下跑 gdb 。
现在我遇到的问题是：debug 和 release 目录下的 make 之间需要 make extraclean (可以理解为所有构建产物都被清除，包括 configure 脚本），导致每次都需要从头构建（耗时长）。
直接创建另外一个单独的源码文件夹，然后这个源码文件夹里的所有的代码文件都是 symlink 到你原本的那个源码文件夹不就行了？
然后 两个源码文件夹各自 autogen 和 configure 各自的。
我没这么试过。在 window 下 symlink 所有文件可靠吗？源码里有好些文件。另外，用什么创建 symblink 呢？是 bash 的 ln ，还是 cmd 的 mklink ？
不如直接在同一 commit 新建分支，使用 worktree 将不同分支放在不同目录，不同分支构建不同版本，但是源码还是一样的。
这个 worktree 和看起来本地 bare 仓迁出到文件系统的两个不同位置类似？如果是，它看上去需要同步两个 worktree 。我的动机恰好和多分支开发相反。
我想的是：只有一份源码，但有两套构建配置。这样，当 release 版本的 emacs 有问题或我想要调试时，可以启动 debug 版本。这两个版本的构建源码是一致的。
我不用 windows 做开发，所以我不是很清楚你问的问题。
但是 symlink 在 windows 上应该可以正常工作的。doomemacs 的包管理大量使用 symlink 来管理包路径。doomemacs 是可以正常在 windows 上运行的。由此我推测 symlink 应该也可以在 windows 正常工作
./configure --prefix=PREFIX 為 release / debug 設不同 prefix 然後 rebuild and make install
这样似仅在 install 时把中间产物安装到不同位置，但没有解决问题 （或者说，没有解决不同构建配置的 build 之间需要额外插入一道 clean 操作，费时） 。
由于部分中间产物输出在源码目录中，导致 debug 和 release 构建存在重叠。如果(1)这两种构建配置的产物（在此问题中为 emacs/lisp/*.elc）不兼容，则 rebuild 必先 clean 。
但如果中间产物都在 build 目录下，make 应该能节省不少时间。
注：前提(1)大概率不成立（见坛友回复），或者说至少目前不成立。不然，我想不通为什么 .elc 编译会到 src 目录下，毕竟 .o 都输出在 build 目录中。