[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Conditional AC_DEFINE with m4_define variable?

From: Jef Driesen
Subject: Re: Conditional AC_DEFINE with m4_define variable?
Date: Wed, 02 Jan 2013 16:03:13 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

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 (with AC_SUBST
>> and a 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
> and, 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]