上一篇文章直接描述了一个node运行的整体流程，导致很多人在群或者cnode中询问如何在本地调试node。因此，我提出这篇文章，让大家对node编译过程和开发有一个整体的了解。
C++编译三部曲
$ ./configure $ make $ make install
相信大家看到这三个命令后，应该都非常熟悉了。 没错，节点编译就是由这三个步骤组成。
接下来我们就从这三个步骤来过一遍node的整体编译流程。
节点编译过程./configure
目标非常明确。 我们赶紧去configure文件看看node的configure做了什么。
好了，原来的关键代码就到这里了，导入了三个模块，分别是：nodedownload（下载模块）、getmoduleversion（获取版本）、gyp_node。 众所周知，node好像是基于gyp编译的。 那么gyp_node模块到底是什么？ 让我们继续讨论tools/gyp_node。
你可以通过gyp_node中的这段代码来阅读。 事实上，最后运行的是node.gyp。 我们的目光跳转到node.gyp，node.gyp是创建文件内容，即python的一个数据结构（类似于json字符串）。 通过筛选其中的target_name，我们可以发现这个gyp_node做了以下几件事（只做比较重要的，感兴趣的朋友可以自行浏览node.gyp）：
接下来，焦点回到gyp_node.py。 以下是一些有趣的代码行：
if sys.platform != 'win32' and 'ninja' not in args: # Tell gyp to write the Makefiles into output_dir args.extend(['--generator-output', output_dir]) # Tell make to write its output into the same dir args.extend(['-Goutput_dir=' + output_dir])
这几行代码将根据target_name在./out文件夹中生成Makefile和*.mk文件，并输入node.gyp：
回到./configure，有几个配置参数需要我们注意：
parser.add_option('--prefix', action='store', dest='prefix', default='/usr/local', help='select the install prefix [default: %default]') parser.add_option('--debug', action='store_true', dest='debug', help='also build debug build')
请注意这两个参数，一个是--prefix，如果不设置前缀，则默认路径相当于全局安装，不利于我们调试，使用时也必须加上--debug参数运行配置。 通过--debug，make可以生成对应的/out/Debug文件夹。 也就是说，如果你想在本地调试，你需要运行的第一步是：
$ ./configure --preifx=your repo --debug
制作
如果我们从make开始，我们可以直接切入makefile。 然后我们都会发现下面的代码：
ifeq ($(BUILDTYPE),Release) all: out/Makefile $(NODE_EXE) else all: out/Makefile $(NODE_EXE) $(NODE_G_EXE) endif
这里分两种情况，上面是Release的情况，下面是configure --debug的情况。 可以看到debug多了一步$(NODE_G_EXE)，虽然查找后是node_g，但是是在debug模式下使用的。 $(NODE_EXE)就不过多介绍了，它是node的执行文件，我们主要看out/Makefile。 不知道大家还熟悉out/文件夹吗？ 没错，是上一步中./configure生成的。 我们去out/Makefile看看这个makefile做了什么。
这里只是一段代码的截图，但是我们已经可以发现上面引用了所有的mk文件mac node源码编译，然后编译一下，因为他已经监听了所有的mk，相当于这里监听了所有node相关的文件，只要 include 关联文件发生改变，就会导致 make 时重新编译 out/Makefile。 接下来我们回到主文件./Makefile：
.PHONY: $(NODE_EXE) $(NODE_G_EXE) $(NODE_EXE): config.gypi out/Makefile $(MAKE) -C out BUILDTYPE=Release V=$(V) if [ ! -r $@ -o ! -L $@ ]; then ln -fs out/Release/$(NODE_EXE) $@; fi $(NODE_G_EXE): config.gypi out/Makefile $(MAKE) -C out BUILDTYPE=Debug V=$(V) if [ ! -r $@ -o ! -L $@ ]; then ln -fs out/Debug/$(NODE_EXE) $@; fi
.PHONY的目标是$(NODE_EXE)$(NODE_G_EXE)，这意味着每次make时这两个目标肯定会运行。 看一下里面的代码。 这两个目标与out/Makefile相关联，而out/Makefile正如刚才所说，他可以窃听所有节点源代码文件。 只要有变化，make时都会重新编译。 通过这组流程mac node源码编译，实际上可以实现以下功能：
make重新编译->节点重新编译并生成">
修改node源码文件->make重新编译->node重新编译生成
如果我们在调试的时候仍然使用编译好的节点，那么似乎只需要改完源码后重新make即可。
进行安装
如果只是为了本地调试，其实可以进入第二步。 make install 相当于将可执行文件安装到第一步定义的 preifx 中。 这里我建议你在git克隆代码时直接克隆到你喜欢的目录。
本地调试和开发节点源码本地编译
本地开发时，我选择的IDE是cLion。 除了一开始生成的cMakefile有点混乱之外，还是不错的。
首先，克隆节点代码：
$ git clone https://github.com/nodejs/node.git
然后，进入节点并运行：
$ ./configure --prefix=your repo --debug
然后执行make操作：
$ make
这样就相当于编译了节点。
导入项目
我们打开cLion并将这个项目放入cLion中。 导入后会手动生成一个CMakeLists.txt。 我们不需要管理这个文件。 调试的时候直接用make就可以了。 因为CMakeLists.txt是手动生成的，只是简单的遍历了c++基础文件，没有对应的链接库，所以即使运行也无法运行。
关联节点
在cLion顶部菜单run->Edit Configuration中，进行如下配置：
确保before launch为空，不要添加build，如果添加build，运行前会调用cmake读取CMakeLists.txt，这不是我们想要的。 对于可执行的可执行文件，选择out/Debug/node。
断点调试
还是昨天的图，在你的编程参数中添加要调试的js文件的地址，然后在node.cc中去断点，然后运行debug看看是否会到达你的断点，没有的话，如果出现意外情况，完全没问题。
Node源码修改调试
如果要修改和调试node源码，仔细看过里面文章的朋友应该已经想到了：更改代码后，通过make编译会触发out/Makefile，从而重新生成out/Debug/node文件，注意 make 的控制台输出：
if [ ! -r node_g -o ! -L node_g ]; then ln -fs out/Debug/node node_g; fi
这里，对out/Debug/node做了一个软链接。 如果是第一次编译，会建立一个软链接，连接到node_g。
通过小菜
文本已成功更新，但遇到了以下错误：
