> "Akim" == Akim Demaille <[EMAIL PROTECTED]> writes:
Akim> I just noticed that Automake replaces all the \-continuation lines
Akim> with a single space, so I can to this for half of the problem:
Don't rely on this.
This is a bug which is already fixed in the cvs automake.
Tom
Akim> This might be useful for some: better support of Autoconf in C-x 4 a:
Lars> Do you have something for us vi-enthusiasts too? ;)
Jason Molenda used to have a vi macro to create a ChangeLog entry. I
don't have it, of course, since I use Emacs. But it is possible to
write one.
Tom
The problems with temporary file security in autoconf's shell scripts
(predictable file names in /tmp, opened without O_EXCL) have been well
known for a long time, though it seems still not fixed in CVS.
AC_SYS_LONG_FILE_NAMES (acspecific.m4) has a similar but much more serious
problem: it uses a
> "Rich" == K Richard Pixley <[EMAIL PROTECTED]> writes:
Rich> AC_PROG_CC tries to link an executable in order to determine
Rich> whether the C compiler is functional. But, of course, at this
Rich> point in my toolchain development, I haven't yet built a crt0.o
Rich> as it's in *this* direct
In a package I'm trying to "autoconf-purify" there is some legacy code
that tries to cope for systems whose signal handlers do not take exactly
one argument of type int. Does anyone know of a system where this is
merited?
Autoconf already figures out the *return* type of signal handlers, but
inci
Date: Sun, 12 Mar 2000 15:11:15 +0100 (CET)
From: Peter Eisentraut <[EMAIL PROTECTED]>
In a package I'm trying to "autoconf-purify" there is some legacy code
that tries to cope for systems whose signal handlers do not take exactly
one argument of type int. Does anyone know of a s
