How to specify different feedback for different platforms if AC_CHECK_HEADER fails in autoconf/configure.ac?

Question

I have a check for a header file in configure.ac in the source root

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

and I'd like to give different feedback on different platform to reflect different most straight forward ways of providing the header:

• on Debian it should error with the message Couldn't find or include log4c.h. Install log4c using 'sudo apt-get install liblog4c-dev'
• on OpenSUSE it should error with ... Install log4c using 'sudo yum install log4c-devel' (didn't research the package name, but you catch my drift)
• on other systems (where I'm too lazy to research the package name) it should error with ... Install log4c by fetching ftp://.../log4c.tar.gz and installing with './configure && make && make install' in the source root

I

• checked the AM_CONDITIONAL macro, but I don't get how to use it in configure.ac rather than in Makefile.am (as described in autoconf/automake: conditional compilation based on presence of library?)
• found the tip to run esyscmd in stackoverflow.com/questions/4627900/m4-executing-a-shell-command, but adding esyscmd (/bin/echo abc) to configure.ac doesn't print anything when I run autoreconf --install --verbose --force.

Both answers describing the usage of conditional macros without the shell commands for the mentioned OS and links to predefined macros (like AC_CHECK_HEADER_DEBIAN, AC_CHECK_HEADER_SUSE, etc.) are appreciated.

The following configure.ac doesn't work:

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

because ./configure fails with

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 :'

There's also ./configure: line 4427: #include: command not found which happens no matter whether AC_CHECK_HEADER is specified.

Answer 1

Your configure.ac is almost ok. The only problem is space between AS_IF and the parenthesis. No whitespace is allowed between a macro name and the opening parenthesis in m4 scripts. This is correct syntax:

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

If you are looking for a way to detect different distros look for example at configure.ac of cgmanager.

Update

I noticed one more problem in your configure.ac.

AC_INCLUDES_DEFAULT macro expands to a set of default includes and can't be used here. It is not needed also. It will be used by default in your AC_CHECK_HEADER macro, as you omit last parameter.

This is the cause of line 4427: #include: command not found error you mention.

Update to your comment

First of all, running a system command itself, like lsb_release is not portable. You should first check, for example with AC_CHECK_PROG, for its presence.

Regarding the syntax I would first get the output of the command using backticks: result=`lsb_release -cs` and later test resulting output: test "x$result" = "xvivid". x is needed to avoid problems with empty value in some shells.

At last, I have doubts whether configure script is a proper place for all this distro specific messages. You may consider placing it in the README file.

Answer 2

Avoid those system specific messages.

Print one message which allows people to figure out what package to install on their respective system, but avoid naming the system specific package names and system specific installation tools.

You will never be able to add messages for all systems, so it is better to go the part of the way which you know and let your users go the rest of the way because they know their systems better than you can.

The proper way would be to write a software package outside but called from your configure which, given a header filename, foo.pc filename, library name, etc. figures out how to install that on the respective system. Then let system specific maintainers fix that package, and call it from configure if it is installed, and issue a generic error message otherwise.

A portable shell script local to your software package might do the same job to some extent. You still have to maintain all the system specific parts for all possible systems, though.

Hmm... now that I am thinking about that, the idea appears not that bad. I might add such a script to some of the projects I maintain and see how it turns out in practical use.

I would still try to keep most of that logic outside configure, though.