autoconf
[Top][All Lists]
Advanced

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

Re: RFC: Changing AC_DEFINE


From: Alexandre Oliva
Subject: Re: RFC: Changing AC_DEFINE
Date: 01 Jun 2001 17:33:39 -0300
User-agent: Gnus/5.090003 (Oort Gnus v0.03) XEmacs/21.4 (Academic Rigor)

On Jun  1, 2001, Akim Demaille <address@hidden> wrote:

> I would like to address the issues raised in
> http://gcc.gnu.org/ml/gcc/2001-03/msg00814.html for 2.51.  This
> basically means try to use `echo' instead of a heredoc when there are
> no funky characters.

Err...  I don't understand how this would help.  I mean, you generally
can't tell at autoconf-time whether there are going to be funky
characters in the macro definition so, in general, you'll need to test
it at run-time, and then, you'll have a here-doc anyway in case there
are funky characters.  Right?

IMO, the best way to go is for autoconf to come up with a safe echo,
i.e., one that won't mess up any characters, will preserve
backslashes, etc, in a similar way that libtool does.  In fact, this
would help libtool a lot as we move more of it into m4sh.

> Just for the record, the figures are quite impressive:

That's just because there were a lot of tests inside a single
statement, i.e., it was something like:

if <cross_compiling>; then
  assume this and that
else
  check this
  check that
  check something else
  on and on forever
fi

A shell parses the whole if/fi construct, creating temporary files for
each here document in it.  Some shells create links for such
here-documents on every fork(), so that the clean-up code they had
installed correctly removes them.  It was in creating the links that
the shell took forever.

Moving the tests out of the if/fi, or creating multiple if/fi
constructs, would improve the performance significantly.  Anyway, this
kind of construct is not exactly the typical use of autoconf.  In
fact, it's even not recommended, because m4 macros can't look into
shell conditionals, so we may fail to expand a macro when it was
expanded before in a conditional path, and the condition turned out to
be false at run-time, and we end up not executing the macro at all.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  address@hidden, redhat.com}
CS PhD student at IC-Unicamp        address@hidden, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me



reply via email to

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