Re: Checking versions and defining macros

[Ralf Wildenhues]

* Jason Curl wrote on Thu, Mar 13, 2008 at 02:15:58PM CET:
> Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:
> > 
> > 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.

> Then I guess you would recommend defining a new macro that would check
> the version of autoconf, if it's new enough (or has the function I
> need) that would just use it, else it would do nothing, or provide a
> replacement.

I would recommend using the "first advice" above first, and only if that
does not work, using version checks.

> Alternatively, is there a AC_CHECK_FUNC but that operates on AutoConf?
> Kind of like, "does autoconf define function X, if not use macro Y
> that I define when I have X in my configure.ac, else just call X
> otherwise"?

I can only guess that you're looking for m4_ifdef, m4_ifndef, and the
like here.  I gave an example of m4_ifdef usage above.


> > 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
> > cleanliness).
> 
> In one particular case, on Solaris 10 I found some cases where LD is
> not in a path, instead of AC_PROG_LD dying with an error message, I
> would have preferred it instead to set a flag that my script can check
> it.

OK.  For such a case there are two alternative strategies I would
recommend:

1) Just pass an LD=... argument to configure.
2) If you can detect the problematic system mechanically with good
confidence, just put the detection code (that then sets $LD) into
configure.ac sometime before the AC_PROG_LD expansion.
3) If you think there is a bug in AC_PROG_LD:
   3a) report it to bug-libtool, get it fixed.
   3b) have a phase-out strategy for your replacement code, by only
       defining the stuff from (2) it in the cases where Libtool is too
       old.

For cases where a simple setting of a variable does not do to override
the broken macro, typically, we do (3b) by just overriding the complete
definition of the macro.  Example:

AC_PROG_INSTALL has a limitation in Autoconf that will be fixed in 2.62.
This is the code I use to provide a replacement definition that will
automatically be dropped with 2.62 or newer:
<http://gcc.gnu.org/ml/gcc-patches/2008-03/txt00016.txt>
(search for config/proginstall.m4).

And please do not skip item (3a), otherwise autotools will not improve.

Cheers,
Ralf