autoconf
[Top][All Lists]
Advanced

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

Re: RFC: Changing AC_DEFINE


From: Akim Demaille
Subject: Re: RFC: Changing AC_DEFINE
Date: 02 Jun 2001 16:19:01 +0200
User-agent: Gnus/5.0808 (Gnus v5.8.8) XEmacs/21.1 (GTK)

>>>>> "Alexandre" == Alexandre Oliva <address@hidden> writes:

Alexandre> 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.

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

I do agree, that's why I referred to AC_VAR_IFINDIR (or whatever the
current name :).  I believe most uses are using literals, and we can
address those cases.

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

Well, why not!  My plan was not to eradicate all the heredocs, but the
trivial ones.


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

Ah, I had not fully understood the diagnostics.  Actually, I think
some part of the thread are missing from the archive.

Thanks!



reply via email to

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