Re: AX_WITH_PERL considered pointless

[Reuben Thomas]

On 22 September 2010 17:36, Francesco Salvestrini <address@hidden> wrote:
> We discussed about them more than a year ago

Sorry for not looking that up.

> Peter suggested to
> obsolete macros only if they were outright broken or if we felt that they were
> utterly pointless, avoiding to remove macros just because they are trivial to
> implement on top of something else.

So, I would like to argue again that they are more of a hindrance than a help.

Reasoning:

1. AX_WITH_FOO is not an improvement on AX_WITH_PROG(FOO, foo).
(AX_WITH_FOO takes optional args, but they're exactly the same as
AX_WITH_PROG's extra optional args.)

2. Experienced users do not want to waste time thinking that
AX_WITH_FOO is giving them something that AX_WITH_PROG isn't. This is
what happened to me.

3. Inexperienced users have less to learn if they just use
AX_WITH_PROG, and as shown above in point 1, it is no harder. If they
use AX_WITH_FOO instead, they will not learn something useful that
they can apply in a similar situation.

In other words, these macros occupy brain space that is better used
for other things.

Finally, a bit of history. From the git logs:

Author: Francesco Salvestrini <address@hidden>
Date:   Mon Jan 28 22:33:11 2008 +0100

    Major re-factoring of Perl, Guile, Python, and Ruby detection macros.

    The new submission AX_WITH_PROG generalizes the technique employed by the
    original AX_WITH_PYTHON to allow for detecting generic executables. Based on
    that macro, trivial wrappers are provided for finding installed versions of
    Perl, Guile, Python, and Ruby.

In other words, these macros used to have a point, because they
existed before AX_WITH_PROG. They no longer have a point.

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

Two more things:

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

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.

-- 
http://rrt.sc3d.org