如果AC_CHECK_HEADER在autoconf/figre.ac中失败，如何为不同的平台指定不同的反馈？

Question

我在源根目录中的configure.ac中检查了一个头文件

AC_CHECK_HEADER(log4c.h,
    [],
    [AC_MSG_ERROR([Couldn't find or include log4c.h])])

我想在不同的平台上给出不同的反馈，以反映提供标题的不同最直接的方式：

• 在Debian上，它应该与消息Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'一起出错。
• 在OpenSUSE上，它应该与... Install log4c using 'sudo yum install log4c-devel'一起出错(没有研究包名，但您理解了我的意思)
• 在其他系统上(我懒得研究包名)，... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root应该会出错

我

• 检查了AM_CONDITIONAL宏，但我不知道如何在configure.ac而不是Makefile.am中使用它(如autoconf/automake:基于库存在的条件编译？中所述)
• 在stackoverflow.com/questions/4627900/m4-executing-a-shell-command，中找到了运行esyscmd的提示，但是在运行autoreconf --install --verbose --force时向configure.ac添加esyscmd (/bin/echo abc)不会打印任何内容。

这两个答案都描述了条件宏的使用，没有上述操作系统的shell命令，以及指向预定义宏(如AC_CHECK_HEADER_DEBIAN、AC_CHECK_HEADER_SUSE等)的链接。都很感激。

以下configure.ac无法工作：

AC_INIT([cndrvcups-common], [2.90], [krichter722@aol.de])
AC_CONFIG_MACRO_DIR([m4])
AM_INIT_AUTOMAKE([foreign -Wall subdir-objects]) 
AC_PROG_CC
AM_PROG_AR
AM_PROG_CC_C_O

AC_MSG_NOTICE([Hello, world.])
AC_INCLUDES_DEFAULT
AC_CHECK_HEADER(check.h,
    [],
    [
        AS_IF (test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
    ])

LT_INIT # needs to be after AM_PROGS_AR
AC_CONFIG_HEADERS([config.h])

AC_CONFIG_FILES([Makefile])
AC_OUTPUT

因为./configure失败了

checking check.h usability... no
checking check.h presence... no
checking for check.h... no
./configure: line 4433: syntax error near unexpected token `;'
./configure: line 4433: `        if ; then :'

还有./configure: line 4427: #include: command not found，不管是否指定了AC_CHECK_HEADER都会发生。

Answer 1

你的configure.ac几乎没问题。唯一的问题是AS_IF和括号之间的空间。在m4脚本中的宏名和开头括号之间不允许空白。这是正确的语法：

AC_CHECK_HEADER(check.h,
    [],
    [
        AS_IF(test "$(lsb_release -cs)" = "vivid", [echo aaaaaa], [echo bbbbbb])
    ])

如果您正在寻找一种检测不同发行版的方法，例如在configure.ac of cgmanager。

更新

我注意到您的configure.ac中还有一个问题。

默认设置宏扩展为一组默认包含，不能在这里使用。这也是不必要的。默认情况下，它将在您的标头宏中使用，因为您省略了最后一个参数。

这是您提到的line 4427: #include: command not found错误的原因。

更新到您的评论

首先，运行系统命令本身，比如lsb_release，是不可移植的。您应该首先检查它的存在，例如，使用AC_CHECK_PROG。

关于语法，我首先使用backticks：result=`lsb_release -cs`获得命令的输出，然后测试结果输出：test "x$result" = "xvivid"。为了避免某些shell中的空值问题，需要使用x。

最后，我怀疑配置脚本是否是所有这些发行版特定消息的适当位置。您可以考虑将其放在自述文件中。

Answer 2

避免那些特定于系统的消息。

打印一条消息，允许人们知道要在各自的系统上安装哪个包，但避免命名系统特定的包名和系统特定的安装工具。

您将永远无法为所有系统添加消息，所以最好按照您所知道的部分进行，让您的用户走剩下的路，因为他们比您更了解他们的系统。

正确的方法是在外部编写一个软件包，但是从您的configure中调用它，给出一个头文件名、foo.pc文件名、库名等，说明如何在相应的系统上安装该软件包。然后让系统特定的维护人员修复这个包，如果安装了它，就从configure调用它，否则发出一个通用错误消息。

软件包本地的可移植shell脚本在某种程度上可能会完成同样的工作。不过，您仍然必须维护所有可能的系统的所有系统特定部分。

嗯..。现在我正在考虑这个问题，这个想法似乎并没有那么糟糕。我可能会在我维护的一些项目中添加这样的脚本，看看它在实际应用中的效果。

不过，我仍然会尝试将大部分逻辑保留在configure之外。