本文永久链接 – https://tonybai.com/2022/09/20/use-viper-to-do-merge-of-yml-configuration-files 作为小厂，我们的基础设施还不够完备，项目经理中秋节通知我们的系统近期要上second-to-last stage环境和生产环境，于是从运维人员部署效率方面考量，我们紧急开发了一个一键安装脚本生成工具，这样运维人员便可以利用该工具结合实际目标环境生成一键安装脚本。这个工具的原理十分简单，如下示意图所示： ...
本文永久链接 – https://tonybai.com/2022/05/16/the-short-guide-of-embracing-c-lang-for-gopher 本文是为于航老师的极客时间专栏《深入C语言和程序运行原理》写的加餐文章《Tony Bai：Go程序员拥抱C语言简明指南》，这里分享给大家，尤其是那些想学习C语言的Gopher们。 你好，我是Tony Bai。 ...
lcut单元测试框架在我的项目中应用已经有一段时间了，项目组的同事对lcut的使用也是越来越熟悉，这不今天一位同事还提出了一个新需求，需求大致是这样的。 在实际项目中，经常遇到这类情况： int bar(…) { int ret; ret = foo(…); /* assert ret */ … ret = foo(…); /* assert ret */ … ret = foo(…); /* assert ret */ … } 上述代码中被测函数接口bar的实现中多次调用了某函数foo。这样当我们用mock方式测试bar这个函数时，可能需要多次重复设置foo的返回值以及输出函数的值，就像这样： ...
昨天在编译项目代码时遇到了这样一个错误： xx_base.h:72:2: 错误：#error “One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined.” 这是预编译器的错误输出。原因很明显：预编译器在处理xx_base.h时没有发现_BIG_ENDIAN或_LITTLE_ENDIAN的定义，#error预处理宏输出了如上错误。下面是出现错误位置的源码片断： ...
有了BuildBot搭建的持续集成环境还远未结束，具体的构建脚本还得自己来写。我们用的是Make工具，对应要编写的脚本就是Makefile。 Make是日常代码构建常用的工具，尤其是绝大多数C和C++项目都会将Make作为首选构建工具。平时多数情况大家都是直接敲入make命令便开始了构建过程，很少有人为make传入什么参数的（调试Makefile的情况除外）。但是有些时候自定义的Make命令行变量还是很有用处的，特别是在将Make与持续集成环境集成的时候。 ...
除了autoconf和automake，GNU的autotools工具包中还有一种工具，它就是libtool。顾名思义，libtool是一个关于库文件制作、安装和使用的工具，它屏蔽了各个平台在库制作、安装和使用方面的差异，为上层提供了统一的接口。你可以直接使用libtool创建静态或共享库，也可以将libtool与autoconf、automake结合在一起使用。第二种方式显然更具实际意义，也更为简单。 在一个使用autoconf和automake构建的编译环境中添加libtool的支持，只需改动几处即可： 首先，你需要在configure.in(或configure.ac)中添加AC_PROG_LIBTOOL宏(注意：去掉AC_PROC_RANLIB宏)。 其次，修改Makefile.am： 如果是建立库文件，则需将lib_LIBRARIES改为lib_LTLIBRARIES，同时将库的后缀名由.a改为.la，这将告诉automake采用libtool来创建相关库： lib_LIBRARIES = libfoo.a => lib_LTLIBRARIES = libfoo.la libfoo_a_SOURCES = libfoo.c => libfoo_la_sources = libfoo.c ...
记得恰好是在一个月前的今天，我发布了lcut(轻量级C语言单元测试框架)0.1.0版本 。由于发布仓促，文档没能及时跟上。在stackoverflow的一个关于单元测试的帖子 上，一位叫Craig McQueen的朋友也给出了建议：“Some documentation would be helpful. Project background and goals, a features list, advantages over existing alternatives, etc would be helpful for people who are checking it out for the first time.” 看完这个建议后心里那个汗啊！不过一想到用E文编写文档心里就有些打怵。就这样在这一个月里文档依旧没有改观:(。不过，lcut本身还是有一些进步的，这两天一直规划着为lcut增加mock的支持，今天终于将这个功能加进了lcut，并发布了lcut-0.2.0-beta版，欢迎大家试用，并提出意见和建议。 ...
今天尝试使用autoconf和automake重新构建一个遗留库的Build环境。之前改造的lcut的目录结构还是相对简单，改造时并未遇到什么难题，不过今天就没那么幸运了，我在头文件目录包含设置这个看似简单的环节上遇到了一些小麻烦。 这个库结构其实也没那么复杂，只是源文件和头文件不在一个目录下罢了： testproj/ – Makefile.am – configure.in – include/ – xx.h – yy.h – module1 – xx.c – Makefile.am – moudle2 – yy.c – Makefile.am 开始也没多想，参照以前的经验一步一步生成configure脚本。执行configure脚本生成Makefile文件，敲入make。在进入module1目录后，提示编译xx.c文件失败，无法找到xx.h！看了一下gcc的编译选项，的确没有-I上层的include目录，只有"-I.“和”-I.."。翻看了一下automake的manual，发现automake默认情况下是将config.h所在的目录当作-I的参数。我的configure.in中是这样设置的:AC_CONFIG_HEADERS([config.h])，怪不得无法正确设置目录呢！将该句改为AC_CONFIG_HEADERS([include/config.h])后，重新生成Makefile并执行make，这回gcc命令行上出现了"-I../include"的字样，编译也很是顺利。 ...
基于各种xUnit框架的单元测试早已不是什么新鲜玩意儿，不过在"古老"的C语言领域，还尚未有哪种框架可以成为“寡头”。 记得2005年末的时候，初出茅庐的我吸取xUnit的设计思想在业余时间编写了一个轻量级的C单元测试框架lcut(Lightweight C Unit Test framework)，当时还写了一篇文章《C单元测试包设计与实现》记录了最初的设计和实现思路。本打算将这个小工具在部门内至少是项目内推广，可无奈当时部门内部尚未认识到使用框架工具进行单元测试的好处，或者尚未形成此种技术风气，当时的我也是“人轻言微”，因此这个小工具也没能吸引足够的眼球。这么长时间以来，都是我自己一直在使用， 其间，lcut做了两次小规模修改。特别是最后一次修改，通过增加测试用例执行的返回状态(增加LCUT_TEST_RESULT()宏)，让lcut可以与一些持续集成工具（如cruisecontrol.rb)结合在一起使用。 ...
部门绝大多数的产品都运行在Sun的小型机上，底层的操作系统是Solaris。这两年公司开始主推刀片机(物美价廉^_^)，不过刀片机上运行的也是Solaris 10 for x86版本。基于同种OS的前提下在Sparc和x86两种体系之间做移植比较简单，主要考虑字节序问题就可以了。不过对于可移植性的考虑不足还是让我们付出了较大的工作量。 在即将进行的新版本产品开发中，可移植性依旧没有被列入到必须要考虑实现的特性列表中，不过从未来产品演化和发展的角度考虑，现在就应该未雨绸缪，在可移植性方面多下工夫！ ...