[Top][All Lists]

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

Re: Checking versions and defining macros

From: Ralf Wildenhues
Subject: Re: Checking versions and defining macros
Date: Thu, 13 Mar 2008 07:27:54 +0100
User-agent: Mutt/1.5.17+20080114 (2008-01-14)

Hello Jason,

* Jason Curl wrote on Tue, Mar 11, 2008 at 10:13:24PM CET:
> If I have autoconf 2.59, I would like to use macro A. But if I have  
> autoconf 2.61, then I'd like to use macro B instead. Ideally, they would  
> be the same name, but might have slightly different definitions,  
> especially if I start to use the internals.
> I would do this, because I've had to modify and borrow implementations  
> from libtool 1.5.24. As autotools don't guarantee internal APIs as being  
> stable, I would warn when autotools are too new, or use a different  
> implementation.

I frequently use unstable versions of the tools, they have version names
such as 2.61a.379-fd8b.  Will you also cater to them?

The first advice should be: if you can detect version differences by
feature based tests, then use those.  For example, if Libtool 2.2 has a
new macro that you need but 1.5.26 doesn't, then you can use
  m4_ifdef([LT_NEW_MACRO], [use new macro], [use replacement code...])

Of course not all differences can be found this way.  So for the rest I
guess you can use
  m4_ifndef([LT_PACKAGE_VERSION], [using Libtool <= 1.5.x ...])

  m4_if([m4_version_compare(m4_defn([LT_PACKAGE_VERSION]), [2.4.38],
        [using Libtool 2.4.38 or newer])

and so on.  m4_PACKAGE_VERSION works similarly for Autoconf.

In general you should try to avoid using internals though, or at least
there should be a phase-out strategy: if you think some internal is
useful enough to be public, then please bring this topic up (on the
respective list) so it's known.  If it isn't, then consider copying
the code to a macro of your own (and rename it, for namespace

Hope that helps.


reply via email to

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