Initial reorganisation

[umarcor]

I forked this repo from kevinpt/hdlparse, as discussed in kevinpt#21 and I invited the following people: @vvvverre, @KatCe, @andresmanelli and @michael-etzkorn.

Since I don't know the state of each of the existing forks, I decided to fork @kevinpt's repo, despite it being behind others. I saw that some forks have shared commits, such as @KatCe's and @andresmanelli's, so let's use this issue (and/or others) to discuss about how to go forward.

I guess the elephant in the room is supporting Python 2.7. It was released in 2010, and after ten years of a very painful deprecation process, it was officially EOL in January 2020 (20 months ago). I believe we should not support Python 2.7 anymore, which should allow cleaning the codebase. Actually, hdl/symbolator requires Python 3, unlike kevinpt/symbolator. Is there any strong opinion/motivation for preserving compatibility with Python 2.7?

Right after deciding that, we should add CI for testing this repo and hdl/symbolator. That will provide us a solid foundation to bring features from existing forks.

/cc @mithro @kevinpt @nobodywasishere @zhelnio @mpkopec

[michael-etzkorn]

I'm in favor of dropping Python 2.7 support. Zhelnio's fork (and vvvvere's fork of that fork) https://github.com/vvvverre/hdlparse has already started a move to python 3.

[vvvverre]

I am also in support of dropping support for Python 2. Does anyone else have a reason why they would prefer to keep Python 2.7 compatibility?

[andresmanelli]

Not really. If this is intended to be an updated/maintained fork it makes sense to move to Python 3 (as you did on hdl/symbolator)

[umarcor]

What's the current compatibility of @vvvverre's fork's master branch with the other forks out there? https://github.com/vvvverre/hdlparse/commits/master
In other words, can we fast-forward this repo to the state of @vvvverre's without meaningful conflicts with others? That would allow us to start with "deprecating" that fork, and then focus on bringing the enhancements from @andresmanelli's and @KatCe's.

[vvvverre]

Having had a quick look at the @andresmanelli and @KatCe forks, I think there shouldn't be any serious conflicts. As luck would have it they mostly focused on the VHDL parser. Myself, and @zhelnio before me, were only making changes to the Verilog parser.

There might be a few small conflicts in minilexer.py, but they should be very minor (mostly relating to Python 2 -> 3).

Does anyone have a different read on this?

[michael-etzkorn]

We should be able to use the vhdl_parser from @andresmanelli fork and the minilexer from @vvvverre's fork. It looks like all merge conflicts in vhdl_parser between the two forks were style related.

[andresmanelli]

Yes, that's right. The @vvvverre fork changed some imports and python3 related calls, but the rest was style related. In my fork there is only one commit that changed the minilexer and almost the same changes were also included in @vvvverre's fork.

[umarcor]

I moved the main branch forward to the state of @vvvverre's fork's master branch. @michael-etzkorn, I saw you did some compatibility tests. Do you feel like proposing some PR(s) to bring enhancements from @andresmanelli's fork?

[michael-etzkorn]

I'm in the middle of bug hunting something, but as soon as I get the chance, I plan to play around with some vhdl and @andresmanelli's vhdl parser. I'm not as familiar with vhdl, but as far as merging goes, I believe we can essentially leave imports untouched and replace the current vhdl_parser.py with his. I'll also be look at what python 3.10 broke with the verilog parser: #3