Re: Debian-specific Autoconf patches

[Ralf Wildenhues]

Hi Paul,

* Paul Eggert wrote on Sun, May 28, 2006 at 12:01:12AM CEST:
> Ralf Wildenhues <address@hidden> writes:
> 
> >> +** AC_TRY_COMMAND, AC_TRY_EVAL
> >> +  These never-documented macros have been marked with a comment
> >> +  saying that they may be removed in a future release.
> >
> > Do you intend to then replace them with something safer?
> 
> I'd rather not promise a replacement now.  If we can think of a better
> way to support the need behind these (never-documented) interfaces,
> fine, but I can't think of one offhand now.  Perhaps after we start
> assuming shell functions....

Well.  Fact is, these macros are widely used, and their usage assumes
the old escaping rules.  Libtool (both 1.5.x and CVS HEAD) uses them,
and breaks hard with this patch, due to the way it uses them.  And yes,
this is horrendously ugly, but look:

  if AC_TRY_EVAL(NM conftest.$ac_objext \| $lt_cv_sys_global_symbol_pipe \> 
$nlist) && test -s "$nlist"; then
      # Try sorting and uniquifying the output.

This has worked with all Autoconf versions from the last half dozen
years; now I simply don't know what to do with it (more instances).
What am I going to replace the above with, so it works with both
Autoconf versions, pre- and post this change?

We cannot sensibly let anyone use Libtool with this in Autoconf.


Furthermore, third-parties use the AC_TRY* macros -- my first test on a
larger package already revealed several M4 quoting errors there, that, if
you don't know what you're looking for, are almost impossible to find by
an unexperienced person.  I can go on testing, but I'm not inclined to.

This patch nullifies all test exposure that we got from any third-party
package testing that anyone of us has done recently, or that the Debian
upgrade to 2.59c or CVS (which was from _before_ this change) has
brought us.  And frankly, I simply don't want to have to redo all the
testing I've been doing.

I very much agree with you that these macros are in some way insecure,
and not nice, and that we need something better.  But I ask you please,
pretty please, let's revert this part of the patch, and post-2.60, let's
create _differently named_ macros which are actually safe, and then
precisely document the escaping methods employed.  And then we get
Autoconf to not use the old ones any more, and _then_ we mark the old
macros obsolete with our usual mechanism of
  AU_DEFUN([...], [...], [Please replace these with safe macros like
  blah blah, but take care: they have different quoting semantics.])

so that users have a grace period to upgrade and not have their old
packages break, we can prepare another Libtool release, and so on...
and two stable releases later, we remove the old macros.  (Yes, let's
make that count based on releases rather than years, to have some
incentive to release something stable more often.)

We really should be starting to only apply patches that fix regressions,
and not worry about potential hazards or minor bugs any more; we're
simply not going to be able to fix all of them before 2.60.  (Autoconf
hasn't worried about potential hazards for years, there is no particular
reason to start doing so right now.)

> > I'm not sure about the best way to solve this: one possibility is to
> > document the "we single-quote all arguments now" strategy, and tell
> > people to use eval to access $ac_configure_args if they have to.
> 
> But there has never been any documentation for ac_configure_args, or
> for how it's to be quoted.  This gives us the freedom to change the
> implementation without breaking published interfaces.

I don't feel good if on the one hand we're not presenting people with a
AC_CONFIG_SUBDIRS macro that fulfills their needs (e.g., you need to
override $CC, say, to build multi-ABI, or whatever else, you're lost, as
you have to get rid of the config.cache command line arguments), but on
the other hand we're also not letting them use the variables they need
to implement a replacement macro.  Sounds like a bad service to our
users to me.  The actual code changes wrt. ac_configure_args are ok:
they don't actually break anything that wasn't broken before.  So I
propose to not do anything here now, but also to not change interfaces
lightly in this area; i.e., make sure to announce when changes happen,
so people know they need to fix their stuff.  (And let's do that early
in a development cycle.)

Cheers,
Ralf