restructuring the repo

[GitMensch]

Splitted from #14:

@GitMensch said:

• Do we need to have the bin directory under version control (especially when we have the binaries in the releases, soon)?
• Do we need to keep the two branches? I think moving the 2.x bison in to the main branch (adding a "new" VS/CMake entry and splitting chocolately into two directories) would be useful (there are actually minor differences in non-bison parts between those branches and it looks like you've did the changes in both (without merging the changes from master to branch).

@lexxmark said:

I agree. Just some notes:

1. bin folder includes non binary stuff. May be we should move it to src/ subfolders and copy to output dir during building? So output dir will have executables and all needed stuff.
2. I usually cherry-pick commits from master to bison2.7 I hope further upgrades m4 code won't break frozen bison2.7 code.

Additional question:

• Are the current VS project files the ones generated by CMake?
• I've spotted automatic ".l" to ".c" in the VS2017 solution - Did I missed it?

Suggested new layout:

• no bin
• bison2 - content of branch bison2.7
• bison3 - moved from bison
• chocolatey
  • bison2 --> content from bison2.7 branch, but download from GitHub Releases
  • bison3 --> content from master, but download from GitHub Releases
• common - as is
• custom_build_rules (moved from bin\Release)
  • doc (new folder with sources of include the documentation for creating VS-build rules in source #15)
  • win_bison_only
  • win_flex_only
• flex - as is
  • src
  • FlexLexer.h (moved from bin\Release)
• build (folders moved one level down but VS-subfolder win-bison renamed to win-bison3 [paths adjusted] and new win-bison2 [the solution will build both])
  • VS2010
  • VS2013
  • VS2015
  • VS2017
  • buildVS2015.bat
  • buildVS2017.bat
  • new: make_dist.bat
• dist (git-ignored)

make_dist.bat will ask for VS version and bison version to use (can be toggled with TAB), copy the binaries from the VS version + data dir from appropriate bison + custom_build_rules + FlexLexer + docs to dist.

@lexxmark I assume you have questions, and answers :-)

[lexxmark]

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)

[GitMensch]

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).

[lexxmark]

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.

[GitMensch]

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?

[lexxmark]

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.

[Croydon]

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.

[lexxmark]

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.

[GitMensch]

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 :-)

[lexxmark]

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.