Re: How to maintain compatibility with Automake.

[Gary V. Vaughan]

On 10 Aug 2010, at 15:19, Peter Rosin wrote:
> Hi!

Hi Peter,

> A macro by the name AM_PROG_AR might be on its way into Automake,
> and I would like to use it sooner rather than later. But I don't
> think it is prudent to require an Automake version which has the
> macro. Would something like this be a workable solution in
> libtool.m4 (untested, needs adjustments to _LT_CMD_OLD_ARCHIVE
> of course)?
> 
> m4_ifndef([AM_PROG_AR],
> 
> ############################################################
> # NOTE: A macro with the same interface as this has been   #
> #  submitted for inclusion into GNU Automake as            #
> #  AM_PROG_AR.  When we require an Automake version which  #
> #  has this macro we should remove this macro from here    #
> #  and use the Automake macro unconditionally.             #
> ############################################################
> [
> m4_defun([AM_PROG_AR],
> [AC_CHECK_TOOLS(AR, [ar], false)
> : ${AR=ar}
> AC_SUBST([AR])dnl
> ])# AM_PROG_AR
> ])

Just like that!

> Or how are situations like this generally handled?

Following, is a somewhat long-winded answer for the list archives
and the search engine indexing bots:

When I wanted to make use of modern (2.64 era) m4sugar facilities
in getopt.m4sh, but maintaining compatibility back to at least
Autoconf 2.62, I took this approach:

  # m4go_expand(ARG)
  # ----------------
  # M4SH_GETOPTS wants to pass unbalanced parentheses to m4_expand to
  # build the branches of a shell `case' statement.  That is only
  # supported by the implementation of m4_expand in Autoconf-2.64 and
  # newer.  Since we want to be compatible back to at least
  # Autoconf-2.62, reimplement our own 2.64 based m4_expand in the
  # m4go_ namespace so that we can be compatible with Autoconf versions
  # supporting either semantic.
  m4_define([m4go_expand],
  [m4_chomp(_$0([$1
  ]))])

  m4_define([_m4go_expand], [...])

However, I was worried about changing semantics between the various
releases, which is why I took a concrete implementation as a copy
of the simplest version, and renamed that into a known namespace.

By contrast, when we submitted AC_PROG_SED to Autoconf, we wrapped
the incumbent Libtool implementation in:

  m4_ifndef([AC_PROG_SED], [
  ############################################################
  # NOTE: This macro has been submitted for inclusion into   #
  #  GNU Autoconf as AC_PROG_SED.  When it is available in   #
  #  a released version of Autoconf we should remove this    #
  #  macro and use it instead.                               #
  ############################################################

  m4_defun([AC_PROG_SED],
  [...
  ])#AC_PROG_SED
  ])#m4_ifndef

The latter is closer to what you're aiming at, and thus I think your
proposal is perfectly fine :)

Cheers,
-- 
Gary V. Vaughan (address@hidden)