Ubuntu | Tony Bai

在Unix/Linux上，我们一般可以通过两种方法查看到一个可执行程序的版本信息，以下以Ubuntu中的Gcc为例。

第一种方法：我们可以直接通过程序名字得到版本信息，例如:
$ which gcc
/usr/bin/gcc
$ ls -l /usr/bin/gcc
lrwxrwxrwx 1 root root 7 2010-08-21 00:18 /usr/bin/gcc -> gcc-4.4*

可以看到我用的Gcc的版本号为4.4，但似乎这个版本信息还不够全，只包含了major和minor版本号，还不包括bugfix修订号。

第二种方法，也是最常见的，获得版本信息最为详细的方法，它就是通过-v或–version命令行选项来查看可执行程序的版本号，绝大多数Unix/Linux下的程序都是支持这种方法的。比如：

$ gcc –version
gcc (Ubuntu 4.4.3-4ubuntu5) 4.4.3

可能有人会认为无论是将版本信息放入程序名字中还是在程序内部加上版本信息，都不是神马难事儿，没有必要单写一篇文章来说明。没错，这些的确不是什么困难的事。

在程序名字中放入版本号，通过Gcc命令即可完成：
$ gcc -o foo-1.3.1 foo.c

如果你使用Makefile来构建你的程序，你可以这样做：

/* Makefile */
TARGET = foo-1.3.1
all: $(TARGET)
gcc -o $(TARGET) foo.c

而在程序内部加上版本信息的最简单方法莫过于在头文件中定义一个宏，然后在version函数中输出这个宏的内容：

/* version.h */
#define VERSION "1.3.1"

/* version.c */
void version() {
printf("%s\n", VERSION);
}

我相信很多朋友都是如是做的。

如果大家真的都是这样做的，那么问题就出现了："当可执行程序的版本信息发生变更时，我们需要修改两个地方"。又有人会说："修改两个地方也不是很麻烦啊"。没错，但这绝不是吹毛求疵，而是实实在在发生的问题。实际开发中很多开发人员总是只记得修改一处，而忘记了另外一处，这样就导致了两处版本信息的不一致。

我们不能完全依靠开发人员的细心和责任心来消除这一问题，我这里提供一种方法供大家参考：

我们在Makefile中像这样定义一组版本信息相关的变量，最重要的是通过一个外部宏定义FOO_VERSION_INFO将版本内容传递到程序内部：

# Makefile

MAJOR := 1
MINOR := 3
BUGFIX := 1

TARGET := foo-$(MAJOR).$(MINOR)

CFLAGS = -DFOO_VERSION_INFO=\"${MAJOR}.${MINOR}.${BUGFIX}\"

all:
gcc -o $(TARGET) $(CFLAGS) foo.c

/* foo.c */
void version() {
/* 这里直接使用Makefile中定义的FOO_VERSION_INFO宏 */
printf("%s\n", FOO_VERSION_INFO);
}

int main() {
version();
return 0;
}

$ foo-1.3
$ 1.3.1

这样一来，即使版本号发生变更了，我们也只需修改Makefile这一处包含版本信息的文件即可。

很多可执行程序的文件名中并不包含版本信息，像ls。如果是这样的话，一切就变得简单了。但是若像Gcc那样，在程序名以及程序内部都包含有版本信息的，我相信使用这个方法/技巧还是大有裨益的。

使用autoconf解决可移植性问题

八月 23, 2011

0 条评论

昨天在编译项目代码时遇到了这样一个错误：

xx_base.h:72:2: 错误：#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."

这是预编译器的错误输出。原因很明显：预编译器在处理xx_base.h时没有发现_BIG_ENDIAN或_LITTLE_ENDIAN的定义，#error预处理宏输出了如上错误。下面是出现错误位置的源码片断：

/* xx_base.h*/
#if defined(_BIG_ENDIAN)
… …
#elif defined(_LITTLE_ENDIAN)
… …
#else
#error "One of _BIG_ENDIAN or _LITTLE_ENDIAN must be defined."
#endif

xx_base.h是部门一基础库中的一个头文件，上面的做法对于基础库自身来说并无太大问题。基础库的Makefile通过检测CPU类型定义了对应的字节序宏，并在编译时作为gcc的命令行选项传入：

/* Makefile */
ifeq ($(CPU), x86)
        DEFS += -D_LITTLE_ENDIAN
else ifeq ($(CPU), sparc)
        DEFS += -D_BIG_ENDIAN
else
        $(error $(CPU) is not supported!)
endif

但是一旦这个基础库被某项目复用，且该xx_base.h文件被项目代码引用，编译就会出现问题，因为各个项目的Makefile中并没有定义_LITTLE_ENDIAN或_BIG_ENDIAN宏。如果基础库不做修改，那么复用该基础库的项目代码中就都需要考虑这两个宏的定义问题。这未免有些"强加"的意味，对于一个几乎被所有项目复用的基础库而言，这样的做法显然不妥。

那如何解决这个问题呢？一个思路是如果基础库在发布后依旧携带这些宏的定义，那就可以避免这样的问题了。在很多使用autotools(包括autoconf, automake, libtool等)协助进行代码构建的开源包中经常会看到一个名为config.h的源文件，那里面包含了与移植相关的宏定义。这个config.h是configure脚本根据config.h.in模板自动生成的。

我们的基础库如果完全用autotools改造显然也可以解决这个问题，但这样一来以前编写的一些构建脚本就要被全部抛弃，能否折中一下呢：利用autoconf生成config.h，但不输出Makefile，依旧使用原先的Makefile？

实验证明这样是可以的。只需对configure.in(或configure.ac)做一些调整即可，将类似AC_CONFIG_FILES([Makefile src/Makefile src/example/Makefile])这样的代码从configure.in中移除即可：

# -*- Autoconf -*-
# Process this file with autoconf to produce a configure script.

AC_PREREQ([2.64])
AC_INIT([baselib], [1.0.0], [xx@gmail.com])

AC_CONFIG_HEADERS([include/config.h])

# Checks for header files.
AC_CHECK_HEADERS([stddef.h stdlib.h string.h])

# Checks for typedefs, structures, and compiler characteristics.
AC_TYPE_SIZE_T

# Checks for library functions.
AC_FUNC_MALLOC
AC_CHECK_FUNCS([memset])

AC_OUTPUT

AC_CONFIG_HEADERS这句是关键！修改完configure.in后，执行autoheader，我们就会在include下发现config.h.in模板文件被生成了出来。执行autoconf生成的configure脚本后，我们在include下就得到了config.h。

下面就是在config.h中加入我们期望的宏。在我们的问题中，我们希望在configure时可以探测到当前host所用的字节序(endianess)，并将结果反映到config.h中。幸运的是autoconf内置了字节序的测试宏AC_C_BIGENDIAN。增加了AC_C_BIGENDIAN测试宏的configure.in经过autoheader处理后得到的config.h.in文件中多了如下这组代码：

/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
# undef WORDS_BIGENDIAN
# endif
#endif

在Sun SPARC小机上运行configure，我们得到的config.h中有关字节序的宏定义代码如下：
/* Define WORDS_BIGENDIAN to 1 if your processor stores words with the most
significant byte first (like Motorola and SPARC, unlike Intel). */
#if defined AC_APPLE_UNIVERSAL_BUILD
# if defined __BIG_ENDIAN__
# define WORDS_BIGENDIAN 1
# endif
#else
# ifndef WORDS_BIGENDIAN
# define WORDS_BIGENDIAN 1
# endif
#endif

config.h中定义了WORDS_BIGENDIAN宏，说明Sun Sparc小机采用的是BigEndian。这样只要基础库的头文件都在最开始包含了config.h，那么上面的问题就解决了。

不过有些朋友不喜欢WORDS_BIGENDIAN这个宏的命名，想自己给标识字节序的宏命名，比如BASELIB_IS_BIGENDIAN。那么我们如何来支持呢？这里我也找到了一个办法：

首先，就是手工编辑config.h.in(注意这之后你就不要通过autoheader生成config.h.in了)，在结尾加上这样一行：
#undef BASELIB_IS_BIGENDIAN

然后，修改configure.in，通过AC_DEFINE来定义一个新的BASELIB_IS_BIGENDIAN宏：

AC_C_BIGENDIAN
if test $ac_cv_c_bigendian = yes; then
AC_DEFINE(BASELIB_IS_BIGENDIAN, 1)
fi

我们通过AC_C_BIGENDIAN的检测结果来确定是否定义BASELIB_IS_BIGENDIAN宏，ac_cv_c_bigendian显然是AC_C_BIGENDIAN内置的一个变量，如果需要，我们也可以模仿其命名规则得到其他测试宏内置的变量。

最后，执行autoconf和configure，我们就可以在include/config.h的结尾看到这样一行定义：
#define BASELIB_IS_BIGENDIAN 1

AC_DEFINE不一定非要与测试宏绑定在一起，它的用法很灵活。如果我们的代码中需要根据不同操作系统的类型来调用不同的代码，那么我们需要在config.h中放置几个标识操作系统类型的宏，比如BASELIB_LINUX和BASELIB_SUNOS。和BASELIB_IS_BIGENDIAN一样，我们首先需要手工编辑config.h.in，增加如下两行代码：

#undef BASELIB_LINUX
#undef BASELIB_SUNOS

然后，修改configure.in，加入自定义的OS测试代码，并且定义对应的宏：

os=`uname -s`
case $os in
    Linux)
        AC_DEFINE(BASELIB_LINUX, 1)
        ;;
    SunOS)
        AC_DEFINE(BASELIB_SUNOS, 1)
        ;;
    *)
        AC_ERROR([host is unsupported.])
        ;;
esac

最后，执行autoconf和configure。如果我们在redhat上，我们就会在config.h中看到如下代码：

#define BASELIB_LINUX 1
/* #undef BASELIB_SUNOS */

autoconf也内置了一系列系统类型测试宏，比如AC_CANONICAL_SYSTEM(依赖install-sh、config.sub和config.guess三个脚本)，其测试后的结果放在了$host变量中，你也可以通过判断$host变量来确定到底在config.h中定义哪个宏。