Bison 3.5.0 released about winflexbison

[ColinFinck]

For what it's worth, this is everything I needed to change in order to get upstream Bison 3.5 to build under Windows using Mingw-w64: https://github.com/reactos/RosBE/blob/master/Patches/bison-3.5-reactos-fix-win32-build.patch
The resulting binary then always needs the BISON_PKGDATADIR and M4 environment variables to be set, but apart from that, it's working fine. And I could use the very same source package for Windows and Linux builds of Bison (which is why winflexbison was no option).

I'm well aware that this patch can't be directly included, but I leave it here as an inspiration.
Happy holidays everyone!

[GitMensch]

@ColinFinck the patch is a good start but not correct in all places:

• instead of the additional check for WIN32 check for HAVE_SYS_IOCTL_H / HAVE TERMIOS_H (for your non-windows build set those via CPPFLAGS during configure, or even better, add them to the configure script
• instead of commenting the winsock define use the existing guard (if you really have the file but don't need / want to include it [btw: why?], then adjust config.h after you've run configure and remove the define HAVE_WINSOCK2_H there

[ColinFinck]

@ColinFinck the patch is a good start but not correct in all places:

As I said, I know pretty well that this patch can't be included into Bison in its current state.
However, I needed a source to build Bison under Windows and Linux now, and this patch makes it possible for me and anyone who's interested.
I hope it can serve as an inspiration for a real patch and I'd highly appreciate if someone could continue from here :)

* instead of the additional check for `WIN32` check for `HAVE_SYS_IOCTL_H` / `HAVE TERMIOS_H` 

Agreed, it's cleaner. But I tried this and gave up, because currently sys/ioctl.h and termios.h are not checked in the configure script and thus their HAVE_ constants are not available.
I wanted to keep the differences to vanilla Bison minimal, so I decided for a WIN32 check instead.

* instead of commenting the winsock define use the existing guard (if you really have the file but don't need / want to include it [btw: why?], then adjust config.h after you've run configure and remove the define `HAVE_WINSOCK2_H` there

Everyone compiling for Windows has this file, so it's always detected and included. However, including winsock2.h pulls in the entire set of Windows headers. This clashes with many definitions inside Bison (like accept and CHAR).
There is no reason why Bison should ever need any Winsock functions or other MS headers, thus it's safe to comment out the #include <winsock2.h> in gnulib for a Bison distribution. I would actually opt for removing this line from upstream gnulib entirely, expecting it to cause more harm than good for most applications. But @ebblake added it in coreutils/gnulib@b5e7a0d to fix something else. Someone should check with him.

Adjusting config.h after running configure sounds like an even worse hack to me. It especially breaks the nice configure, make, make install scheme.

[lexxmark]

@donmac703 please check new version win_flex_bison-2.5.22.zip works on your grammar files.

[lexxmark]

For what it's worth, this is everything I needed to change in order to get upstream Bison 3.5 to build under Windows using Mingw-w64

@ColinFinck Thank you for sharing your work with us.
The main intention of win_flex_bison package was to completely avoid using unix tools like M4 and fork function. Mingw-w64 tries to mimic this functionality on windows.

win_flex_bison uses different approach - by deep code refactoring give users minimal self-contained executables compatible with original flex/bison tools.

There was no goal to keep code similar as much as possible.

[donmac703]

Hi Lexxmark,
I have not had much time to focus on this, but initial indications show that the release is working correctly and reflecting the upstream changes.
Thanks for getting this release done.

[GitMensch]

done with https://github.com/lexxmark/winflexbison/releases/tag/v2.5.22