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

#include "config.h"

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

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

const char *
dc_version (dc_version_t *version)
        return DC_VERSION " (" DC_VERSION_REVISION ")";
        return DC_VERSION;

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.


reply via email to

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