Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Bison 3.5.0 released #49

Closed
donmac703 opened this issue Dec 14, 2019 · 7 comments
Closed

Bison 3.5.0 released #49

donmac703 opened this issue Dec 14, 2019 · 7 comments
Assignees

Comments

@donmac703
Copy link

The upstream Bison 3.5.0 has been released.
See https://lists.gnu.org/archive/html/bison-announce/2019-12/msg00001.html

@lexxmark lexxmark self-assigned this Dec 15, 2019
@ColinFinck
Copy link

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
Copy link
Collaborator

@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
Copy link

@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
Copy link
Owner

lexxmark commented Jan 8, 2020

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

@lexxmark
Copy link
Owner

lexxmark commented Jan 8, 2020

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
Copy link
Author

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
Copy link
Collaborator

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants