Re: Checking versions and defining macros

[Jason Curl]

Ralf Wildenhues <Ralf.Wildenhues <at> gmx.de> writes:

> 
> 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?

No, as I generate the "configure" files and deliver this and know precisely my
development environments. But I wouldn't barf, just print a warning it's
untested. I might get smarter and try to compare versions and say if it's 2.61*
then Macro A, or if 2.59* then Macro B.

> 
> 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.

Good - that solves one problem with 2.57 not supporting some macros I need, but
those macros are just printing out warnings (e.g. help messages).

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.

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"?

> 
> 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.

Instead I had to copy the macro into a new file (actually at the moment I
override the macro by giving it the same name) and to another check which fixes
my problem, and then give an error. The idea is, AC_PROG_LD exists for all
versions, but their internal implementations change and hence may break with
future versions of libtool.

This is why I want to check for particular versions of autotools, "import" a
relevant macro and use that.

Then in my project I also reuse a bunch of macros from AutoConf (like
AC_CHECK_DECL, AC_CHECK_LIB) that do checks, but don't cache or don't print
messages, allowing me to reduce the clutter on the output and also making my
configure scripts simpler by not having to work around cache results that I need
to then throw away.

> 
> Hope that helps.
> 
> Cheers,
> Ralf
>