熟悉了Shell，还应该学Makefile吗？

Shell、Makefile、自动编译...



分类：验证平台设计

这个问题，可能对大部分验证工程师来说，都不是问题，因为“习惯的力量”。对于一个部门或公司而言，习惯的力量是很强大的。我们之所以应用一种脚本语言，因为在这里，大家都这么用。

初级的验证工程师，最先接触的脚本语言多是Shell。除了linux的terminal本来就是Shell外，另一个重要的原因是Shell是解释型语言。

解释型语言：

“解释型语言:程序不需要编译，程序在运行时才翻译成机器语言，每执行一次都要翻译一次”，“比如Python/JavaScript / Perl /Shell等都是解释型语言”……摘自360或百度。

对于解释型语言的优点：调试较方便，所见即所得。程序运行到哪里了，哪个变量什么值，通过简单的打印就可以获取。而且编写的时候，格式要求不是特别严格，写起来比较方便。

因此，对于刚刚接触验证的新员工而言，使用Shell编写仿真验证脚本，相对来说，能够降低编写仿真脚本的复杂度，让新员工能够将精力集中到仿真验证本身。对于仿真验证脚本的选择，一般情况下，我还是推荐使用Shell。

当然，也有使用Makefile进行仿真验证管理的，但说实话，我对Makefile一直还是比较抵触的，感觉Makefile不够亲切。大家一起来感受一下。



个人以为实在是有些高冷的：

1、  语法不够直白，请解释一下x:all是个什么鬼？“IUS =”又在做什么？

2、  语法要求严格，Tab的位置绝对不能写空格，例如L47行的@前；

3、  不能随便添加调试信息，如想在L42行打印一下$(UVM_HOME)，这个在Shell中非常方便的操作，在Makefile中就需要添加不少信息。

Makefile的语法不够直白，语法要求严格，调试较为困难。给我的感觉就是上面提到的：不够亲切！

那么，既然我们已经熟悉了Shell脚本了，还有没有必要学习Makefile呢？我建议还是回到我们的工作场景中来讨论。

近期，我做了一件奇葩的事情，使用Shell脚本，将我们SOC验证使用的软件代码做了编译管理。效果怎样呢？总结为：写起来方便，用起来麻烦！

Shell作为一种解释型语言，就是从头到尾一步步执行。先编译公共代码，然后在编译C语言用例，最后链接，一步步倒是蛮清晰的。而且，即使把代码放到多个目录，编写起来也没有多少困难，毕竟有sed命令可以用。

但Shell脚本没有一个Makefile脚本中，非常有意义的一个概念：依赖关系！

即使代码比较少，但是，看到那些已经编译过无数遍的代码，又被编译一遍，心烦！

某个代码编译有问题，但是Shell脚本依然开开心心的执行下去了，直到报告链接错误，心烦！

编译错误要从一堆编译正确的log中搜索出来，而不是向上翻两行就好了，心烦！

这时候，深切的感受到Makefile的意义了：

1、  代码有更新才编译，没有更新直接使用之前的结果，当然，Shell也可以做，就是麻烦；

2、  某个代码更新了，会影响到的代码才编译，不影响到的代码不编译，当然，Shell也可以做，就是超级麻烦；

3、  如果代码有错误，可以直接退出编译，检查代码错误，不会继续执行下去，当然，Shell也可以做，就是麻烦！

麻烦，麻烦，真麻烦！对于软件代码的编译，我的建议还是：用Makefile！《跟我一起写Makefile》的作者，总结为“makefile带来的好处就是——‘自动化编译’”。这个总结非常到位，当然，您需要深刻理解“自动化编译”包括了以上提到的Makefile的诸多优点，如自动判断代码更新；自动产生约束关系；基于目标的管理，如果目标不达到，自动退出等等。

因此，我的建议是：

1、  仿真脚本使用Shell脚本，调试比较简单；

2、  软件编译使用Makefile脚本，使用方便。

好了，今天就先到这里吧，对于脚本，您有什么心得或不同意见，可以在公众号留言，也可以扫描下方的二维码，加入“IC验证工程师交流群”讨论。



本文为原创，转载请注明出处：IC验证工程师

    关注 IC验证工程师