Menu
▾
▴
#11 Split between Core and Eclipse
We currently have a hard dependency on Eclipse, even when running a standard command-line compiler flow. This has become a sticking point when considering future maintenance and development. We could ease future maintainability by making a clear split between PHDL Core and PHDL Eclipse Plugin.
How exactly and/or if and when to most effectively make this split is a topic best discussed on the phdl-devel mailing list rather than through bug commentary.
Discussion
Anonymous
I think this will be necessary. I fear that the Eclipse, Xtext, Java project is not maintainable due to complexity.
I believe that a simple Antlr, Java project could be maintainable. We should also consider a complete rewrite for simplified maintenance. Now that PHDL syntax is defined we should also consider a super simple, g++ only, implementation.
Pete
Do we have documented anywhere or does anyone care to explain the differences between the 2.0 and 2.1 grammars and language features?
Just looking at the phdl-2.0 tree vs. the phdl-2.1 tree shows an enourmous difference in the amount of complexity. I could see the 2.0 tree as a starting point for a reduced complexity core if we wanted to use it as a baseline.
I've got a list of specific changes between the 2.0 and 2.1 grammers themselves. But they are also written with different syntaxes, (one in x-text and one in the antler syntax) so there is quite a big difference in implementation and a large difference in how the ASL trees are actually structured.
Here is a link to a google doc with a list of differences between the two grammers. It may not have all of the changes, but it has what I could see from a quick comparison of the two: https://docs.google.com/document/d/1nsWWH-xj7D5j9z7UL5UFcvh0EsYJG91pLgZM3CspPOA/edit
I also think that we should have this discussion on the mailing list soon.
We should try and find specifically what the grammar should be defined to be.
If we do go the route of rewriting the project using Antlr, I think there are some significant additions in the 2.1 grammar that could probably be implemented in Antlr as well. If we are going to do a complete rewrite as Pete suggested before, (which probably would be quite easier to maintain) I think we may want to implement a grammar as close to the current updated 2.1 grammar as possible, in-order to use some of the necessary added functionality such as the ability to modify attributes of devices instanced down within the chain of hierarchy, which can be very useful when creating complex designs.
Wes mentioned in another bug report about creating a standardized "canonical" documentation version of the grammar. Doing this first with the complexity and features of the plugin and the simplicity and maintainability of a java and Antlr or g++ project in mind would probably be a good place to start.
Thanks for documenting the changes between the two grammars. Would you mind if I convert that document to a textual format and stick in the repository? (Google docs are handy, but not easy to publically version control.)
I definitely think we don't want to lose any features that were added in 2.1 (unless we lose them on purpose, by leaving them out of our language spec!) -- and it would be shame to lose eclipse support for those that want to maintain it -- even though I personally don't care about it.
I think if we just get the grammar defined well in a canonical document, then the eclipse plugin and a "plain" version could co-exist just fine. We should discuss this more on the mailing list rather than in the bug comments, but important points or decisions should be noted here.
No that would be fine if you want to convert it and put it in the
repository. I think we're still getting used to how opensource projects
usually go. Thanks for your help!
On Wed, Oct 10, 2012 at 5:44 PM, Wesley J. Landaker wjl@users.sf.netwrote: