[Top][All Lists]

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

Re: Strategy to specify major, minor, and patch versions

From: Eric Blake
Subject: Re: Strategy to specify major, minor, and patch versions
Date: Thu, 28 Aug 2014 04:28:56 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.7.0

On 08/28/2014 02:05 AM, Zé wrote:

>> It should also be possible to do the reverse: declare m4
>> macros and shell variables up front for major/minor/patch, then generate
>> AC_INIT by calling those macros rather than open-coding the version.
> That would be preferable.  Is there any way to pull that off?  I've
> tried with variables, but nothing behaved quite as I expected it to
> behave.  For example, say there these variables are declared in
> prior to calling AC_INIT:
> let's say the intended outcome is to pass the version number to AC_INIT,
> so that it would be equivalent to:
> AC_INIT([foo], [1.0.0])


# M4 macros, for use during autoconf time...
m4_define([MAJOR_VERSION], [1])
m4_define([MINOR_VERSION], [0])
m4_define([PATCH_VERSION], [0])

# Now reflect it for use during configure time...
m4_divert_text([DEFAULTS], [

But that approach will let you use the m4 macros that expand as needed
(calling AC_INIT([foo], [1.0.0]) as desired) as well as letting your
configure start with shell variables (a line such as MAJOR_VERSION=1).
Actually, picking _different_ names for the m4 macros than for the shell
variables may make use of it less confusing, particularly if you also
end up wanting to AC_DEFINE a substitution variable for use in C code.
Hope that gives you some ideas.

Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library

Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

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