Re: Conditional AC_DEFINE with m4_define variable?

[Jef Driesen]

On 31-12-12 22:21, Eric Blake wrote:> On 12/22/2012 09:07 AM, Jef Driesen wrote:
>> On 22-12-12 16:18, Eric Blake wrote:
>>> [adding autoconf, as this question technically is independent of
>>> automake]
>>>
>> What I want to accomplish is as follows. I have a dc_version() function
>> in my library which returns the version number. The main part of the
>> version number is generated directly from configure.ac (with AC_SUBST
>> and a version.h.in file). But I also generate a revision.h file at build
>> time containing the git SHA1. So far no problem. But now I'm trying to
>> append this git revision info for non-release builds (e.g.
>> dc_version_suffix not empty).
>
> You may be interested in seeing how GNU Coreutils approaches this.  It
> uses a tool git-version-gen from gnulib, as well as some hooks into
> configure.ac and Makefile.am, so that if you are building from
> coreutils.git, then the git version is injected as a suffix into the
> generated version string via a file version.[ch], and if you are
> building from a tarball, then the information is hard-coded and there is
> no suffix.  By sticking the version information in a separate .c file,
> it becomes merely a matter of linking to the new .o file (rather than
> recompiling the world) when the version number changes.

I already have something like this in place.

>> So my version.c file contains roughly this:
>>
>> #ifdef HAVE_CONFIG_H
>> #include "config.h"
>> #endif
>
> Within a single project, you should know whether you are using config.h;
> being conditional only matters for libraries like libtool that are
> designed to work even without autoconf.  That is, these days, most
> people _don't_ need #ifdef HAVE_CONFIG_H, but can blindly assume that it
> is in use.

I also support building my project with msvc, and in that case there is no 
autoconf...

>> So I wanted to have this USE_REVISION macro somehow end up in the
>> config.h header, such that the above code would work.
>>
>> The m4_ifset based test does that, but if the dc_version_suffix is
>> empty, the USE_REVISION macro is not present in the config.h file at
>> all. Usually when you define any sort of tests (e.g. AC_CHECK_*), then
>> the corresponding macros always ends up in the config.h file, but
>> uncommented when not available. Like this:
>>
>> /* Use the revision number. */
>> /* #undef USE_REVISION */
>
> Ah, so you want the template to be visible to autoheader, even when the
> template is not in use from a tarball.

It's not a must, but because that appeared to be the normal behavior, I thought 
I might be doing this the wrong way, and I just don't want to rely on something 
that might break in unexpected ways. That's all.

>> When using an AS_IF based test, that's the case too. So that's why I
>> thought the m4_ifset test was not the right tool.
>
> Yeah, m4_ifset hides the entire AC_DEFINE from view of any other tool,
> like autoheader, that scans for m4 calls.  If you want the template to
> appear unconditionally, but only be defined when needed, you might try:
>
> if m4_ifset([dc_version_suffix], [:], [false]); then
>    AC_DEFINE([USE_REVISION], [1], [Use the revision number.])
> fi
>
> which then makes the AC_DEFINE() unconditionally expanded at m4 time (so
> autoheader will list the template), but the shell decision on whether to
> do anything is now minimized.

I already implemented the direct m4_ifset call. No need to add extra complexity 
if not absolutely necessary :-)

Anyway, thanks for your time and feedback! It helped me a lot to understand what 
is going on.

Jef