restructuring the repo about winflexbison HOT 9 OPEN

I've just thought - may be we could just freeze bison2.7 branch.
Just stop maintain it, don't cherry-pick new win_flex versions and win_bison fixes.

So anyone who wants use new versions of flex or fixed bison should upgrade its bison files to 3.x.x. version.

Only if someone explicitly ask us to fix something in bison 2.7 I will modify bison2.7 branch.
I hope that will never happen though.

from winflexbison.

Additional question:
Are the current VS project files the ones generated by CMake?

No, they are handmade. CMake support was added recently and doesn't impact to existing project structure.

I suggest to leave in build folder VS20XX folders for last two versions only (VS2015, VS2017).
I'm not sure VS2013 and VS2010 are working now.

I even agree to completely remove build folder and stay with CMake option only.

I've spotted automatic ".l" to ".c" in the VS2017 solution - Did I missed it?

I don't understand, please clarify it.

Suggested new layout:

I fully agree with your proposal. Just some notes I mentioned above (about build/ folder)

from winflexbison.

I suggest to leave in build folder VS20XX folders for last two versions only (VS2015, VS2017).
I'm not sure VS2013 and VS2010 are working now.

If you want to, but I should be able to at least verify that 2010 is working, too (and provide older versions, at least down to 2005 [if building with this compiler works]).

I even agree to completely remove build folder and stay with CMake option only.

Only if you insist on this and if you do we should provide a new "source" distribution along with the binaries for new releases (it is always bad when you have to install CMake, check howto use it (even when .bat files for this are provided) just because you want to build something.

I've spotted automatic ".l" to ".c" in the VS2017 solution - Did I missed it?

I don't understand, please clarify it.

There are flex source files in the source-tree and we even build flex first - but the c source files aren't generated (or I've missed this).

from winflexbison.

If you want to, but I should be able to at least verify that 2010 is working, too (and provide older versions, at least down to 2005 [if building with this compiler works]).

if you want to and have possibility to make projects to all VS versions down to 2005 you could do it.
But I don't think many developers building win_flex/win_bison by their own. The main value of these tools - they could be run on any windows system down to Windows XP. So the most majority of developers just use executable available in release. The other part of developers that (for some reason) have to build executables by their own is very small. And I guess they don't need VS2005-VS2013 projects so we could skip it until someone explicitly request it.

Only if you insist on this and if you do we should provide a new "source" distribution along with the binaries for new releases (it is always bad when you have to install CMake, check howto use it (even when .bat files for this are provided) just because you want to build something.

I agree let's stay with pure VS projects. And CMake as alternative option.

There are flex source files in the source-tree and we even build flex first - but the c source files aren't generated (or I've missed this).

I've copied *.l files just for consistency. They are don't used now. During upgrade I grab new bison code from the original repository and I don't modify *.l file, so it's enough to have *.c generated original files.

from winflexbison.

There are flex source files in the source-tree and we even build flex first - but the c source files aren't generated (or I've missed this).

I've copied *.l files just for consistency. They are don't used now. During upgrade I grab new bison code from the original repository and I don't modify *.l file, so it's enough to have *.c generated original files.

So the "c generated original files" are from an outdated flex version - which is the reason why I think it would be good to (either manually or automatically) rebuild these with the flex version built beforehand, don't you think?

from winflexbison.

So the "c generated original files" are from an outdated flex version

No. The *.c generated files are from flex version that was used by bison maintainer when he wrote bison code. In theory new version of flex could break bison code. So I think it's maintainer's responsibility to regenerate *.c generated file with a new version of flex and ensure everything is OK.

• which is the reason why I think it would be good to (either manually or automatically) rebuild these with the flex version built beforehand, don't you think?

My goal was to make minimal modifications of the original bison code to make it run under windows. I think any modifications in the code that would benefit bison tool should be done in original bison code and then propagated to win_bison during version upgrade. Otherwise we have hard fork of bison and it would be more difficult to merge changes from original repo.

from winflexbison.

I'm disagreeing with merging the two branches. In my humble opinion it has the potential for more confusion and it's harder to oversee with no clear benefit.

I'm agreeing that there shouldn't be built win_flex and win_bison binaries in the git repository as this is exactly what releases are for.

from winflexbison.

This was my fault to place 3 projects: common_lib, win_flex and win_bison into a single git repository.
It should be 4 repos:

1. common_lib - master
2. win_flex - master
3. win_bison - master/bison2.7
4. winflexbison - master/bison2.7 - has all above repos as submodules.

This will allow me eliminate redundant cherry-picking.

I've removed exe files.

from winflexbison.

Using sub-modules sounds reasonable.

Just a note: to allow compilation of win_flex or win_bison you already need common_lib, so this would mean to have 2-3 "not self-contained" repos. If you want to do this:

• copy .gitattributes/.gitignore to bison(master/2.7), flex and common_lib
• split the subfolders into a new repo
• change winflexbison to use the repos as submodules instead of the folders

When you did this I'll:

• add a README.md to the new repos mentioning their not-self-contained-ness (and how to compile them / locally make them self-contained)
• add license note to the new repos
• adjust the build folder as described in the first post
• add make_dist to the winflexbison
• close this issue

Or... just go with the approach of the first post - should solve the issue without any not contained repos.
@lexxmark Again - your choice :-)

from winflexbison.