Re: [Mingw-users] bison 3.0.2 and m4sugar.m4

[Eli Z. <el...@gn...>]

> Date: Mon, 06 Oct 2014 07:37:46 +0200 (CEST)
> Cc: min...@li...
> From: Werner LEMBERG <wl...@gn...>
> 
> 
> > Bison should work regardless of its configure-time --prefix
> > setting.
> 
> How shall this work out of the box?

I said "should".  In this case, the original Bison code doesn't
provide such a feature, so I needed to add it in my own build (using
GetModuleFileName).  Sorry, I should have been clearer on that.

> If you build with msys, the default prefix `/usr/local' definitely
> points into msys.

I never build on Windows without an explicit --prefix argument.  It is
not useful to do otherwise, as the result will be at best unreliable
and at worst simply won't work.  /usr/local is not an absolute file
name on Windows, and even if it happens to exist on some drive, it
will not be what you intended.

> If I move bison out of the tree, the m4 files in the `/usr/local/'
> hierarchy are no longer found...  So I have to set the undocumented
> `BISON_PKGDATADIR' environment variable to circumvent this...

Not if the executable is "relocatable", i.e. can look for the files
relative to its own location.

> > Do you have m4.exe installed, and is that m4.exe a MinGW program or
> > an MSYS program?  It should be a MinGW program.
> 
> Now I have two m4.exe programs.  The first comes with msys and fails
> for my non-msys bison.  Then I've rebuilt m4.exe with the standard
> `./configure; make; make install' incantation into a prefix outside of
> msys (the same as with my new bison program for convenience).  This
> makes it a MinGW program, right?

If you compiled with MinGW GCC, then yes.

> Finally, I've rebuilt bison, assuring that bison's `configure'
> program really uses the newly built m4 executable.  After adjusting
> PATH to make the new bison and m4 be found first, it still fails in
> both the `cmd' and `msys' shell.

Ah, that rings a bell.  Do you have a line in your config.h saying
something like

  #define M4 "/d/foo/bar/m4"

If so, that's the culprit: the configure script records that file name
in the MSYS format, and then bison tries to use it, and fails.

I resolved this by forcing the M4 value at configure time:

   M4=m4.exe ./configure ...

This kills 2 birds: it solves the above problem, and it causes
bison.exe to look for m4.exe on PATH, rather than insist on finding it
in some specific place -- again, a boon if you move the binary.

> > If you need an MSYS bison, and there's no newer version on the MinGW
> > download site, you need to build it.  I never build an MSYS program,
> > but AFAIU you will need an MSYS development environment, available
> > from the download site.
> 
> Sigh.  I guess I'm out of patience now.  The whole issue has cost me
> more than two days, with zero results.

I'm sorry to hear that.  I presumed that you are working with a
debugger to solve these issues, because then you'd see immediately the
reason for the above problem.

There are a couple of other issues with Bison 3.0.2 on Windows (yes, I
built it just today, so now I know ;-).  If you still want to build
your own, I can send you the patches.