Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Thoughts on Fortran and Language Independence

Greetings all,

On behalf of the Photran team, I apologize that we haven't been responding to the discussions on Fortran and language independence. In short, this is because we don't know what the "right" answer is (although we've discussed it a lot... see below).

My understanding is that our goal is to eventually have a language-neutral plug-in (CLDT/UDT/XDT) and separate plug-ins for C/C++, Fortran, and other compiled/gdb-able languages that extend it. (Maintaining Fortran support as part of the CDT codebase is out of the question for more reasons than I care to list.)

The majority of the changes between the CDT and Photran were textual substitutions in the user interface. Making these language-neutral is easy... if it isn't C/C++-specific, put it in the CLDT UI, and make the name more generic. We might have a Compiled Language Development Perspective, a generic Standard Makefile Project (shared by all languages), and a menu item to Run Local Binary Application.

In the code, though, we inherit a *lot* of functionality from the CDT, and separating the generic parts from the C/C++ or Fortran-specific parts is going to require some serious thought and discussion. The editor is a great example. A lot of it had to be customized... but we inherited the preference pages and user-specified syntax colors "for free."

I am not ready to tackle the topic of what to do with the ICModel/ICElement heirarchy. Our current Outline view is more accurately called the Proof of Parser View, and our present concern is designing a refactorable AST/symbol table setup for a 31-page Fortran 95 grammar (an annoyingly tedious and time-consuming task). We disabled pretty much every form of browsing and and are basically ignoring the indexer, so beyond giving us an Outline, it isn't doing much for us anyway. (Optimal? No, but the thing works, and no one has complained!) I believe that we could eventually have a single CLDT project type shared across multiple compiled languages, and (especially then) a hierarchy like this will be useful. Reusing the C/C++ nodes to represent a Fortran program doesn't seem like the right answer, but neither is taking the union of features in C/C++ and Fortran, if we want to support other languages. And I don't know that code well enough to suggest a better abstraction.

Below, I have pasted snippets of some e-mails between members of our team discussing our perspective on this issue and describing it in a little more detail. In short, a CLDT is going to be worthwhile, but it's also going to require a significant amount of commitment and discussion both from us (including LANL) and the CDT team. (And, if I'm lucky, a trip to Ottawa...)


If I were to summarize our position on what we want from a language-neutral CDT, I think it would be...

(1) We don't care if we "plug into" the CDT or if we're a separate entity, as long as...

(2) Constructing Photran "properly" is not significantly more difficult or time-consuming than the present cut-and-paste routine, ...

(3) Upgrades to the CDT code base have a minimal effect on us; i.e., staying current with the CDT will be less work than cutting and pasting together a new hacked CDT each time, and ...

(4) All of the current features in Photran are still supported (including the New Fortran Project wizard and, if possible, a Fortran perspective).

Our goal is to work on automated refactorings for Fortran and HPC; Photran is simply a platform for this work. Our reason for basing our code on the CDT was to get a lot of functionality "for free." Our reason for wanting to "plug into" a language-neutral CDT is to reduce the cost of upgrading alongside the CDT -- essentially, to get upgrades "for free" as well. A "hacked" CDT code base is not very pretty, but if it is the only economical way to do what we want to do, we'll take it.

Our approach of cloning the CDT, and subjecting it to a Fortran makeover has a number of advantages:

1) It can be accomplished quickly, at least the second time around, without a deep knowledge of Eclipse and the CDT's structure
2) Such an approach would allow Photran and a CDT to coexist in the same
workspace, hence allowing C and Fortran resources to coexist too
3) Maintaining our own modified codebase allows the CDT to evolve without us
4) It makes cosmetic changes trivial (search/replace)
5) It makes disabling non-applicable functionality feasible

This said, there are some downsides:

1) Tracking CDT changes requires that we redo all our modifications
2) The bulk of our code duplicates vast swaths of CDT code in all but a few superficial respects

The CDT folks, LANL folks, and we all agree that making the CDT more friendly to new languages is a worthwhile goal.

It would be nice were customization doable using XML and a few new, language-specific plug-ins. Heading all the way towards plugging in a grammar and a few style sheets is a long way off, though.

Managed build, standard build, and some of the wizards are probably quite close to being customizable using XML forms only, were the plug-ins themselves sharable across perspectives.

There are likely a number of plug-ins where we changed only strings, and where a single "internationalization"-style effort would make them more reusable. The same disclaimer may apply.

There are yet other places where language dependencies are more difficult to avoid: lexing, parsing, editing, and, to some extent, browsing. We may want to keep language-specific perspectives in the mix.

Adding "natures" to the CDT is not necessarily the answer. In fact, having separate natures for C and C++ seems to be an incorrect use of the technology. It might even be possible to have two project types (Standard and Managed Make), encompassing C/C++ as well as Fortran and other languages.

Eclipse is build out of plug-ins, and each plug-in is a singleton. Of course, these singletons can, in turn, wield such resources as they see fit to exhibit multiple personalities. We need to ponder how to best address this, I'm not ready to take a stand on the best way to do this yet.

Superficially, we would like to supply a Core and UI and tie into the CDT's facilities for Make, Launch, and Debug. Of course, we don't want to *completely* build the Core and UI from the ground up. Without really investigating what of this is already possible, some of the more interesting issues seem to be... (BTW, I probably left out some things, and these aren't very well thought out...)

1.For outlining, we would like to reuse part of what the CDT already has. Building a TreeView from scratch should not be necessary. If this means subclassing appropriately to build a model similar to theirs, I think that's a reasonable solution.

2.The editor... we get a LOT for free (e.g., associated preference pages), but we're also changing a lot (syntax highlighting, eventually many other things like content assist and auto-indentation). Basically, we need a starting point that is richer than JFace Text. (Note that we may eventually want to cut over to parser-guided syntax highlighting.)

3.The rest of our UI is coming for free (right?): the Fortran perspective, the Fortran project wizard, the import wizard, the preference pages, etc. Somehow we should continue to get all that without any real effort.

4.We have many wondrous error parsers that need to plug into the (shared) Make system. (I think this is already possible via extensions, but I haven't looked carefully, much less tried...)

5.To what extent is the CDT's indexer reusable? Fortran Search could bring up some other interesting integration issues.

6.Our take-it-or-leave-it attitude toward gdb debugging probably won't suffice for other projects.


Warm regards,

Jeff Overbey
University of Illinois at Urbana-Champaign
Software Architecture Group, Photran Team

<<End cdt-dev post with length rivaling _War and Peace_>>

Back to the top