----- Original Message -----
From: "Earnie Boyd" <earnie_boyd@...>
To: "Luke Dunstan" <coder_infidel@...>
Cc: "MinGW Users" <mingw-users@...>
Sent: Saturday, February 01, 2003 6:23 PM
Subject: Re: [Mingw-users] Snapshot: bison-1.875.0-2003.01.31-1.exe
> Luke Dunstan wrote:
> > I tried building this to examine the text vs. binary issue you mentioned
> > the release notes, but most of the testsuite (e.g. beginning with test
> > fails because it can't find m4. The problem is that config.h contains:
> > #define M4 "/bin/m4"
> > so of course _spawnvp() fails. I haven't downloaded your binary but I
> > just wondering what configure option (or whatever) you used to get
> > this? Ideally bison should build for MinGW without requiring any
> > options but I don't know if this is your goal.
> I cheated and modified the config.h by hand. You can also set M4
> environment variable to point to c:/msys/1.0/bin/m4 or perhaps even just
> m4 (Hmm, maybe the define shouldn't be absolute).
> I agree that it
> should build without requiring modification. I'm not sure what to
> modify though, perhaps autoconf, perhaps bash?
I'm not sure either. The configure script checks the value of $M4, but it
only uses it if it is an absolute path (I don't know why, but I guess it
doesn't matter here). The way that configure searches for m4 in PATH is a
bit redundant when execvp/_spawnvp do it anyway, but I think it really comes
down to the difference between the standard way of finding executables on
Unix vs. Windows (hardcoding vs. relative). However, in the case of MSYS we
can't find m4 relative to the location of bison anyway, and a hardcoded path
is no good so the only option is to search for m4 in PATH. Possibly just
something like this:
#define M4 "m4"
It could go in system.h just after config.h is included. I don't know if
something like that would be acceptable in the official m4 sources though.
> BTW, if you add a -w to the diff command found in the testsuite script
> in the tests directory, you'll see two failing test cases, otherwise
> there are more. The MSYS diff treats \r as white space, that's how I
> knew I had missed some output modes to binary.
These tests are affected by line ending differences: 4 39 40 41 42 104
Actually you didn't miss any because the carriage returns are in the output
of the bison-generated parser executables, not the output of bison itself.
Note that if the bison source package was in DOS format (e.g. if you checked
it out using a Windows CVS client), it would match the output of the
programs, and you wouldn't need to change any of the fopen() calls to use
binary. It would be better, though, if we used a version of "diff" that
treated CRLF the same as LF instead of treating CR as whitespace. If MSYS
diff can be modified it would be okay, but maybe we could use a Win32 native
diff instead (like Manu's port)? Of course other scripts and MSYS tools may
depend on the output of diff being in Unix format.
These tests have a problem with sed: 21 23
The input text is echoed as you would expect when not passing the -n option
to sed, but the sed script also has a special comment "#n" on its first
line, which is supposed to have the same effect as -n according to the sed
manual. I can confirm that this is a bug in MSYS sed, and strangely the bug
is also in the Gnuwin32 port, but Cygwin's sed works. See sed/compile.c:408
in the sed source.
When I run the full set of tests, it initially reports that these tests have
failed for some reason: 85 91 92 95-103
However, later when the tests are rerun in verbose mode they succeed, and
they also succeed if I run them individually from the command line, in
verbose mode or not (e.g. "./testsuite 85"). Apparently the exit status is
being set somewhere that it shouldn't be, but I haven't found how. You said
that only two tests failed for you (presumably 21 and 23), so didn't you see