automake
[Top][All Lists]
Advanced

[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: Sat, 22 Dec 2012 17:29:55 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0

On 22-12-12 16:18, Eric Blake wrote:
> [adding autoconf, as this question technically is independent of automake]
>
> On 12/22/2012 07:52 AM, Jef Driesen wrote:
>> Hi,
>>
>> When I set a variable with:
>>
>> m4_define([dc_version_suffix],[devel])
>>
>> or leave it empty:
>>
>> m4_define([dc_version_suffix],[])
>>
>> And then try to conditionally call AC_DEFINE based on whether the
>> dc_version_suffix is set or not, this doesn't work:
>>
>> AS_IF([test "x$dc_version_suffix" = "xdevel"], [
>>     AC_DEFINE(ENABLE_PTY, [1], [Enable pseudo terminal support.])
>> ])
>
> This will expand to either:
>
> test "x$" = "xdevel"
>
> or
>
> test "x$devel" = "xdevel"
>
> based on the macro value.  Probably not what you wanted.

That explains very well, why it doesn't work. I wasn't really aware of the
difference between m4 and shell variables.

>> However if I use m4_isset, then it does kind of work, except that the
>> USE_REVISION macro in the config.h is either defined, or not present at
>> all.
>>
>> m4_ifset([dc_version_suffix],[
>>     AC_DEFINE(USE_REVISION, [1], [Use the revision number.])
>> ])
>
> Indeed, this actually does what _I_ would want - since dc_version_suffix
> is known at m4 time, we might as well use that information to generate
> the smallest possible configure.
>
> But if you _insist_ on delaying the decision until shell time, even
> though the condition being tested is known at m4 time, then you probably
> want to use something like this:

I do not insist on doing things in a particular way. I just want something that
works and preferably done the right way  See below for an explanation of what
I'm trying to achieve.

>> Does anyone know how to implement this correctly?
>
> It really depends on what you are trying to accomplish by deciding
> something at m4 time, but deferring the action on that decision until
> configure time.

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). So my version.c file
contains roughly this:

#ifdef HAVE_CONFIG_H
#include "config.h"
#endif

#include <libdivecomputer/version.h> /* Defines the DC_VERSION macro. */

#ifdef USE_REVISION
#include "revision.h"/* Defines the DC_VERSION_REVISION macro. */
#endif

const char *
dc_version (dc_version_t *version)
{
#ifdef USE_REVISION
        return DC_VERSION " (" DC_VERSION_REVISION ")";
#else
        return DC_VERSION;
#endif
}

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 */

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.

Jef




reply via email to

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