* 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: <> (search for config/proginstall.m4). And please do not skip item (3a), otherwise autotools will not improve. Cheers, Ralf