Inception在编译的时候的一个大坑！！！

最近在使用自动化审核工具Inception的时候，遇到了一个大坑，之前的公众号推送文章中也有写到Inception工具的环境配置问题，当时讲到了两个方法，分别是官网提供的基于脚本的sh inception_build.sh debug [Xcode]方法和基于cmake的cmake . 然后make && make install的方法，当时不太明白这两种方法的区别，知道今天在实战中遇到了一个大坑，才明白这两种安装方法的区别，这里说明一下：

1、基于脚本的方法

inception_build.sh是Inception提供的安装运行脚本，直接运行

sh inception_build.sh debug [Xcode]

即可执行安装Inception，此脚本的安装目录在inception-master/debug/sql目录下，Inception会将编译的应用程序客户端放在该目录下，即Inception，用户在启动时可以直接进入该目录，然后./Inception --port=6669 &从而进行后台运行。之所以会将编译结果定向到这个目录，是因为脚本中控制的结果，我打开了inception_build.sh这个脚本，看到了如下的代码：

从图中可以看出，Inception自动生成了一个debug的目录，第二个白框中的程序说明这个脚本inception_build.sh中也是调用的cmake && make && make install，所以两种安装方式上本质上没什么区别，但是为什么要多定义一个debug的目录呢？？？先抛出这个问题，一会儿回答。

2.cmake && make && make install

这是最常见的编译文件的方式，写cmakelist文件，然后进行编译，此方法看似没有什么异常之处，然而编译的过程中，会将Inception的编译结果，自动放置在你的/usr/local/mysql/bin/目录下,从而直接覆盖你原本的客户端。这样当你启动mysql服务时，你会发现：

你的mysql客户端被覆盖了，你没法看到自己的数据库内容了。此时查看mysql的data文件，发现data文件还在，还好，可以恢复！！！

重新复制一份好的mysql客户端，然后把原来的客户端文件夹覆盖掉，OK，发现可以用了，结果如下：

现在应该很好理解为什么要重新创建一个客户端了吧，就是为了防止生成的

Inception应用程序覆盖掉原先的mysql服务，从而导致mysql实例无法启动。此时启动Inception，直接进入/usr/local/inception/debug/sql，然后运行：

Inception --port=6669 &

出现：

即为成功！！！

总结：

在编译Inception时，最好使用官方推荐的sh inception_build.sh debug [Xcode]方式进行编译。