autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Debian-specific Autoconf patches


From: Paul Eggert
Subject: Re: Debian-specific Autoconf patches
Date: Wed, 31 May 2006 01:45:38 -0700
User-agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux)

Ralf Wildenhues <address@hidden> writes:

> I didn't have any such headaches before the patch.

I did.  The problem had been bothering me for some time.  And when I
saw the AC_TRY_COMMAND-related bug report that started this thread, I
realized the problem was worse than I thought.

> I am slowly running out of time checking whether
> the new version now breaks oodles of packages, or not.

It is helpful and admirable of you to be doing all this checking
against other people's software.  But doing all the checking will burn
you out -- at least, it would burn _me_ out, and almost anybody else I
would think.  It would be more efficient to enlist others to help, and
in the end, with luck, you'll be saner and will have more time to do
more-productive things.

For AC_TRY_COMMAND and AC_TRY_EVAL I followed your good suggestion:
namely, leave them alone, but keep them undocumented and deprecated,
and eventually we can come up with a better approach with new macro
names.  However, I don't see how this suggestion would generalize well
to the multitude of other predefined macros (AC_CHECK_FUNC,
AC_CHECK_LIB, etc., etc.).  Unlike AC_TRY_COMMAND and AC_TRY_EVAL,
these other macros are documented and are quite commonly used.  It
would be a bit much to rename all these macros simply to fix an
obscure shell quoting problem that hardly ever leads to disaster
(except when deliberately provoked, alas).  So we will have to bite
the quoting bullet with these macros anyway.  It is only a question of
judgment as to whether it's better to do it now (as per the current
CVS) or after 2.60 is out (or more likely, after 2.61 or 2.62 or
2.63....).

We can try enlisting others to test snapshots, with Debian and the
like.  If we find further problems you can easily talk me into
reverting the eval-quoting changes, but right now I'm still inclined
to leave them in.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]