Re: AX_WITH_PERL considered pointless

[Peter Simons]

Hi Reuben,

 > I would be happy to do the necessary work to obsolete them.

you are right, those macros are fairly trivial and don't add much to the
ease-of-use of AX_WITH_PROG. I mean, if you can't figure out how to use
AX_WITH_PROG, then no wrapper can help you. :-)

Yet, macros like AX_WITH_PERL have been around for a very long time, and
removing them might come as a surprise to users who may have relied on
those definitions for several years. Would it be possible to provide
some sort of automatic updating, like the one described in the Autoconf
documentation?

 | 10.5 Obsoleting Macros
 | ======================
 |
 | Configuration and portability technology has evolved over the years.
 | Often better ways of solving a particular problem are developed, or
 | ad-hoc approaches are systematized.  This process has occurred in many
 | parts of Autoconf.  One result is that some of the macros are now
 | considered "obsolete"; they still work, but are no longer considered
 | the best thing to do, hence they should be replaced with more modern
 | macros.  Ideally, `autoupdate' should replace the old macro calls with
 | their modern implementation.
 |
 |    Autoconf provides a simple means to obsolete a macro.
 |
 |  -- Macro: AU_DEFUN (OLD-MACRO, IMPLEMENTATION, [MESSAGE])
 |      Define OLD-MACRO as IMPLEMENTATION.  The only difference with
 |      `AC_DEFUN' is that the user is warned that OLD-MACRO is now
 |      obsolete.
 |
 |      If she then uses `autoupdate', the call to OLD-MACRO is replaced
 |      by the modern IMPLEMENTATION.  MESSAGE should include information
 |      on what to do after running `autoupdate'; `autoupdate' prints it
 |      as a warning, and includes it in the updated `configure.ac' file.
 |
 |      The details of this macro are hairy: if `autoconf' encounters an
 |      `AU_DEFUN'ed macro, all macros inside its second argument are
 |      expanded as usual.  However, when `autoupdate' is run, only M4 and
 |      M4sugar macros are expanded here, while all other macros are
 |      disabled and appear literally in the updated `configure.ac'.
 |
 |  -- Macro: AU_ALIAS (OLD-NAME, NEW-NAME)
 |      Used if the OLD-NAME is to be replaced by a call to NEW-MACRO with
 |      the same parameters.  This happens for example if the macro was
 |      renamed.

If we could offer Archive users a transition period to update their
code, say, 6 months, then I feel it would be fine to ultimately delete
those wrappers.


 > 1. Obsolete macros should have an expiry date (N years from the point
 > of obsolesence, for an agreed, preferably integral, value of N).

Yes, that is a good policy. In the past, things were sort-of done this
way. There is no automatic expiry process, though, so "N years" really
means "we'll delete them at some point in the future when some git user
thinks it's probably okay to do so".


 > 2. I'd like to disagree that we should be "avoiding to remove macros
 > just because they are trivial to implement on top of something else".
 > Macros that are both trivial and obvious to implement on top of
 > something else should certainly be removed, as they waste time, both
 > of autoconf-archive maintainers and users. I say "and obvious"
 > because sometimes there are trivial non-obvious uses of macros which
 > are worth naming precisely because they would otherwise be missed by
 > users.

Yes, I agree that trivial and obvious wrappers can be safely deleted
(and/or merged into the documentation of the macro that they build
upon).

Take care,
Peter