From: "Tim Van Holder" <tim DOT van DOT holder AT pandora DOT be>
To: "DJGPP Workers Mailing List" <djgpp-workers AT delorie DOT com>
Subject: Two glitches for autoconf 2.49b
Date: Sat, 30 Dec 2000 10:16:42 +0100
Message-ID: <NEBBIOJNGMKPNOBKHCGHOECGCAAA.tim.van.holder@pandora.be>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="Windows-1252"
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by delorie.com id EAA05453
Reply-To: djgpp-workers AT delorie DOT com

Hi,

I've run into two glitches when preparing autoconf 2.49b.

First off, it includes (help2)man pages for config.guess
and config.sub. This leads to clashing LFNs (config.x and
config.1). I can rename these to config_guess.1 and
config_sub.1, but that makes for non-intuitive names (who
would run 'man config_sub' to find out about config.sub?).
Suggestions for such a case are welcome.

Secondly, a more annoying problem was encountered: when
running a freshly built and installed autoconf 2.49b to
configure itself, I got the following error:

== start of output
Target of redirect is not a filename.
configure.in:3: error: m4_file_append: cannot write: h:/Tmp/ac5030/forbidden.rx
m4sugar.m4:1640: m4_init is expanded from...
configure.in:3: the top level
== end of output

After grepping several source trees, I traced the error message
to djgpp's src/libc/ansi/stdlib/system.c.

The relevant m4 macro is:

== start of snippet from m4sugar.m4
# m4_file_append(FILE-NAME, CONTENT)
# ----------------------------------
m4_define([m4_file_append],
[m4_syscmd([cat >>$1 <<_m4eof
$2
_m4eof])
m4_if(m4_sysval, [0], [],
      [m4_fatal([$0: cannot write: $1])])])
== end of snippet

It seemed to me that the shell here document was the culprit.
Now it was easy enough to rebuild m4 with __system_flags set
to '__system_call_cmdproc | __system_use_shell' (and setting
my SHELL envvar to $DJDIR/bash.exe instead of $DJDIR/bash, as
system() barfs if you leave off the .exe (why?)).
But which is more acceptable: requiring a custom m4 or adding
'export DJSYSFLAGS=6' to the scripts of the autoconf suite?
Personally I'd go for the m4; it's a trivial change, so if
whoever maintains that could upload a patched version to
simtel, I'd be happy. After all, it seems unlikely that an
m4 syscmd() would be used to run a DOS-specific command.