lexxmark
Implemented compatibility to MinGW-w64
Thank you for the contribution, looks quite good.
Most changes are to "common" sources and therefore would be broken after we get the next new version in if we don't ensure that we keep those changed lines. Did you provide those patches "upstream" already? That should fix all feature builds, would provide an additional set of eyes and would benefit more people.
Other than that I think we should also adjust .appveyor.yml to actually build a mingw-w64 environment. You did use cmake to generate the result of your patched environment, didn't you? How does your procedure differ from the appveyor definition (we should be able to get that in with a conditional)?
Most changes are to "common" sources and therefore would be broken after we get the next new version in if we don't ensure that we keep those changed lines. Did you provide those patches "upstream" already?
Yes. But I don't think flex and bison are concerned about supporting proprietary ecosystems, like software for Windows. If they were, there would already have been Windows support, directly in upstream, without any need to have a separate project like this one for that. So I haven't bothered.
Other than that I think we should also adjust .appveyor.yml to actually build a mingw-w64 environment.
Absolutely. BTW, I am long cross-compiling software (but I haven't tried that on this project) on Linux, using MinGW+CLang as toolchain (using CMake toolchain files) and Wine for testing. It may make sense to setup this kind of build too.
You did use cmake to generate the result of your patched environment, didn't you?
Yes, I used CMake.
How does your procedure differ from the appveyor definition (we should be able to get that in with a conditional)?
I usually use CMake + ninja. AFAIK it can be used with cl.exe too.
there would already have been Windows support, directly in upstream
Actually the two files that you've adjusted are part of gnulib which actually supports even (only newer) VC versions and also mingw environments, especially for the purpose of cross-compiling.
So please check their git repo for the current sources and if those needs adjustments, if yes sending them upstream, for example via the mailing list, if not then we should be able to copy those sources (you may want to check for other updated sources and create a PR to include those here).
Can you please try to include the mingw environment into appveyor? As this one is about supporting it we can do this here, too - as soon as you commit it is auto-included in the checks (I offer to co-work on this if you miss experience with appveyor, but would not like to be too integrated into anything mainly cmake related...).
Ping @KOLANICH - Did you already reached out to gnulib? If there's an update in the next weeks we may could include those with the Bison 3.7.2 update #60 (or the version after). @lexxmark Did you update the gnuib components before? It would be reasonable to do so in any case.
@KOLANICH Any update to add a mingw environment to appveyor.yml?
Did you already reached out to gnulib?
I haven't managed to find time for that yet. Feel free to do it yourself.
Did you update the gnuib components before? It would be reasonable to do so in any case.
I did it if new gnulib required for new flex/bison code. I usually grab code from bison source files.
Can you please try to include the mingw environment into appveyor?
May I suggest using msys2/setup-msys2@v2 on github actions instead?
The current state is: it just don't build with cmake and MSYS2 currently; as soon as it does the GH action is very reasonable to use and I'll have a look at this then. @KOLANICH can you please recheck?
... but actually there are packages for MSYS2 for both bison and flex, too, so people that do want to use mingw64 may use those already (no matter: a build with MSYS2 would be a good step too add automated testing #17).
@GitMensch I think you can refer to my GitHub Action in another repo to see how to use the GitHub Actions to build for multiple environment at once, even for cross-compiling for the embedded systems.
