* 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
_______________________________________________
Autoconf mailing list
Autoconf@xxxxxxx
http://lists.gnu.org/mailman/listinfo/autoconf
