| % Interactions with CDT |
| \vspace{-0.5in} |
| |
| {\scriptsize Revision: \footnotesize \$Id: cha-cdt.ltx-inc,v 1.1 2010/05/21 20:12:20 joverbey Exp $ $ - based on 2008/08/08 nchen} |
| |
| \section{Introduction} |
| |
| The C/C++ Development Tools (CDT)\footnote{See |
| \url{http://www.eclipse.org/cdt/}} provide support for C and C++ development |
| in Eclipse. CDT uses \textit{make} to compile projects, and it includes an |
| integrated debugger which is actually a graphical interface to \textit{gdb}. |
| |
| In 2006, we contributed a patch to CDT\footnote{See |
| \url{https://bugs.eclipse.org/133386}} which provides an extension point |
| allowing its core infrastructure to support languages other than C and C++. |
| This is appropriate for any language for which code is compiled using |
| \textit{make} and debugged using \textit{gdb}.\footnote{The exact mechanism |
| is described in J.~Overbey and C.~Rasmussen, ``Instant IDEs: Supporting New |
| Languages in the CDT,'' \textit{Eclipse Technology eXchange Workshop at |
| OOPSLA~2005 (eTX 2005),} San Diego, CA, October 17, 2005, and a tutorial |
| on the topic was given at EclipseCon~2006. The details (and code) are now |
| outdated, but the concepts are still applicable.} |
| |
| Photran builds upon the CDT by |
| \begin{itemize} |
| \item plugging into this extension point (org.eclipse.cdt.core.language). |
| This allows CDT to recognize Fortran source files as ``valid'' source |
| files in C/C++ projects, and it allows Photran to provide the outline |
| structure for these files which is displayed in the Navigator and the |
| Outline view (this structure is called the ``model'' and is discussed |
| below). |
| \item subclassing many of CDT's user interface elements (or copying and |
| modifying them when necessary) to provide an IDE for Fortran that |
| looks and works similarly to CDT. |
| \item contributing \textit{error parsers} which allow CDT to recognize |
| error messages from many popular Fortran compilers and display them |
| in the Problems view. |
| \item contributing new project templates and toolchains, which are shown |
| in the New C/C++ Project dialog |
| (and, of course, the New Fortran Project dialog). |
| \end{itemize} |
| |
| \section{C Projects vs.~Photran Projects} |
| |
| Prior to version~6.0, C projects and Fortran projects were treated identically. |
| As of version 6.0, there is an important distinction: |
| \begin{itemize} |
| \item every Fortran project is also a C project, but |
| \item not every C project is a Fortran project. |
| \end{itemize} |
| |
| In technical terms, |
| Fortran projects are C projects that also have a Fortran nature. |
| They must be C projects in order to be ``recognized'' by CDT, but |
| they must also have the Fortran nature so that Photran can display |
| project properties for them and index them without affecting C/C++ |
| projects that do not contain Fortran code. |
| |
| \section{CDT Terminology} |
| |
| The following are CDT terms that will be used extensively when discussing |
| Photran. |
| |
| \begin{itemize} |
| |
| \item There are two types of projects in CDT:\footnote{In earlier versions of |
| CDT, these were actually distinct. CDT overhauled their build system in |
| version~4(?), and these are now treated uniformly in implementation. |
| Nevertheless, this distinction was made frequently in historical discussions |
| about CDT, and it is important to be aware of. It is also a useful distinction |
| to make from the user's perspective, since the idea of hand-writing a makefile |
| seems to intimidate many Fortran programmers.} |
| |
| \begin{itemize} |
| |
| \item \textbf{Standard Make projects} require users to |
| supply their own Makefile, typically with targets ``clean'' and ``all.'' |
| CDT/Photran cleans and builds the project by running \texttt{make}. |
| (``Standard Make'' is actually old terminology; recent versions of CDT |
| call these ``Makefile Projects.'' They are created by choosing |
| Makefile Project $>$ Empty Project and selecting ``--~Other Toolchain~--'' |
| in the New C/C++ Project dialog.) |
| |
| \item \textbf{Managed Make projects} are similar to standard make projects, |
| except that CDT/Photran automatically generates a Makefile and edits the |
| Makefile automatically when source files are added to or removed from the |
| project. The \textbf{Managed Build System} (MBS) is the part of CDT that |
| handles all of this. |
| |
| \end{itemize} |
| |
| \item \textbf{Binary parsers} are able to detect whether a file is a legal |
| executable for a platform (and extract other information from it). CDT |
| provides binary parsers for Windows (PE), Linux (ELF), Mac OS X (Mach~O), and |
| others. Photran does not provide any additional binary parsers. |
| |
| \item \textbf{Error parsers} are provided for many compilers. CDT provides a gcc |
| error parser, for example. Photran provides error parsers for Lahey Fortran, F, |
| g95, and others. Essentially, error parsers scan the output of \texttt{make} for |
| error messages for their associated compiler. When they see an error message |
| that they recognize, they extract the filename, line number, and error message, |
| and use it to populate the Problems View. See |
| Appendix~\ref{ap:creating_an_error_parser} for an example on how to create an |
| error parser. |
| |
| \item CDT keeps a \textbf{model} of all of the files in a project. The model is |
| essentially a tree of \textbf{elements}, which all inherit the (CDT Core) |
| interface \texttt{ICElement}. It is described in the next section. |
| |
| \end{itemize} |
| |
| \section{The Model} |
| |
| The Fortran Projects view in Photran is essentially a visualization of |
| the CDT's \textit{model}, a tree data structure describing the contents |
| of all Fortran Projects in the workspace as well as the high-level contents |
| (functions, aggregate types, etc.) of source files. |
| |
| Alain Magloire (CDT) described the model, A.K.A. the \texttt{ICElement} |
| hierarchy, in the thread ``Patch to create ICoreModel interface'' on the cdt-dev |
| mailing list (April 1, 2005): |
| |
| {\footnotesize |
| \begin{quote} |
| \begin{verbatim} |
| So I'll explain a little about the ICElement and what we get out of it for |
| C/C++. |
| |
| The ICElement hierarchy can be separated in two: |
| (1) - how the Model views the world/resources (all classes above ITranslationUnit) |
| (2) - how the Model views the world/language (all classes below ITranslationUnit). |
| |
| How we(C/C++) view the resources: |
| - ICModel --> [root of the model] |
| - ICProject --> [IProject with special attributes/natures] |
| - ISourceRoot --> [Folder with a special attribute] |
| - ITranslationUnit --> [IFile with special attributes, e.g. extensions *.c] |
| - IBinary --> [IFile with special attributes, elf signature, coff etc] |
| - IArchive --> [IFile with special attributes, "<ar>" signature] |
| - ICContainer -> [folder] |
| |
| There are also some special helper classes |
| - ILibraryReference [external files use in linking ex:libsocket.so, libm.a, ...] |
| - IIncludeReference [external paths use in preprocessing i.e. /usr/include, ...] |
| - IBinaryContainer [virtual containers regrouping all the binaries found |
| in the project] |
| |
| This model of the resources gives advantages: |
| - navigation of the binaries, |
| - navigation of the include files not part of the workspace (stdio.h, socket.h, etc) |
| - adding breakpoints |
| - search |
| - contribution on the objects |
| etc..... |
| |
| [...] |
| |
| (2) How we view the language. |
| |
| Lets be clear this is only a simple/partial/incomplete view of the language. For |
| example, we do not drill down in blocks, there are no statements(if/else |
| conditions) etc .... For a complete interface/view of the language, clients |
| should use the __AST__ interface. |
| \end{verbatim} |
| \end{quote} |
| } |
| |
| \pagebreak |
| |
| From another of Alain's posts in that thread: |
| |
| {\footnotesize |
| \begin{quote} |
| \begin{verbatim} |
| Lets make sure we are on the same length about the ICElement hierarchy. |
| It was created for a few reasons: |
| |
| - To provide a simpler layer to the AST. The AST interface is too complex |
| to handle in most UI tasks. |
| - To provide objects for UI contributions/actions. |
| - The glue for the Working copies in the Editor(CEditor), IWorkingCopy class |
| - The interface for changed events. |
| - ... |
| |
| Basically it was created for the UI needs: Outliner, Object action contributions, |
| C/C++ Project view and more. |
| |
| The CoreModel uses information taken from: |
| - the Binary Parser(Elf, Coff, ..) |
| - the source Parser(AST parser) |
| - the IPathEntry classes |
| - the workspace resource tree |
| - The ResolverModel (*.c, *.cc extensions), ... |
| |
| to build the hierarchy. |
| \end{verbatim} |
| \end{quote} |
| } |
| |
| \shabox{The CDT model should \textbf{not} be confused with the Abstract Syntax |
| Tree (AST) that is discussed in Chapter~\ref{cha:ast-vpg}. They are |
| \textbf{not} identical. It is helpful to think of the CDT model as containing a |
| \emph{partial/simplified view} of a program's structure (representing only the |
| high-level/organizational elements in the source code: program units, subprogram |
| declarations, etc.) \textbf{as well as} a model of the current workspace |
| resources (Fortran projects, Fortran source files, binary executables). In |
| other words, the CDT model knows about the resources and the organizational |
| units in the source code. The AST, |
| on the other hand, completely models \emph{everything} in a single source ilfe---including |
| low-level elements like individual statements and expressions---but knows |
| nothing about projects, folders, etc.} |
| |
| By conforming to the CDT model, Photran is able to reuse various UI |
| elements for \emph{free}. For instance, the Outline View for Photran is managed |
| by CDT; Photran just needs to provide a CDT-compatible model to represent its |
| project and source files. |
| |
| The \texttt{FortranLanguage} class (in the org.eclipse.photran.cdtinterface |
| project) is responsible for initializing concrete |
| classes that will build up the model that CDT expects. |
| |
| There are \textbf{two} options for creating suitable \emph{model builders}: |
| \begin{enumerate} |
| \item The org.eclipse.photran.cdtinterface plug-in project defines the |
| \\ \texttt{org.eclipse.photran.cdtinterface.modelbuilder} extension point that |
| other plug-ins can extend. Plug-ins extending that extension point are |
| responsible for providing a suitable model builder. Using this option, it is |
| possible to have multiple model builders. The model builder to use can be |
| selected in the workspace preferences (under Fortran $>$ CDT Interface). |
| |
| \item If there are no plug-ins that extend the |
| \texttt{org.eclipse.photran.cdtinterface.modelbuilder} extension point, then |
| Photran falls back on a default implementation provided by the |
| \texttt{EmptyFortranModelBuilder} class (which, not surprisingly, builds |
| an empty model). |
| \end{enumerate} |
| |
| The Photran VPG (see Section~\ref{sec:virtual_program_graph}) inside the |
| org.eclipse.photran.cdtinterface.vpg project uses the first option to |
| contribute a model builder. The relevant classes are under the |
| \texttt{org.eclipse.photran.internal.core.model} package (notably, |
| \texttt{FortranModelBuilder}.) |
| |
| As mentioned in the post by Alain, all model elements must implement the |
| \texttt{ICElement} interface for CDT to recognize them. In Photran, the |
| \texttt{FortranElement} class implements the \texttt{ICElement} interface and |
| serves as the base class for all Fortran elements such as subroutines, |
| functions, modules, variables, etc. Each subclass of \texttt{FortranElement} |
| corresponds to an element that can be displayed in the Outline View. |
| |
| \section{Reusing UI Elements} |
| |
| Various UI elements in Photran are also reused from the CDT. |
| |
| \begin{itemize} |
| |
| \item Many elements are reused directly. |
| |
| \begin{itemize} |
| |
| \item Photran frequently instantiates or references |
| classes from CDT and uses them as-is. For example, |
| the \texttt{FortranProjectWizard} uses CDT's |
| \texttt{ICProjectDescription}. |
| |
| \item It is also common for plugin.xml |
| files in Photran to reference contributions from CDT. For example, the |
| XML declaration for the Fortran perspective includes the line \\ |
| \centerline{\texttt{ |
| <actionSet id="org.eclipse.cdt.make.ui.makeTargetActionSet"/> |
| }} \\ |
| which adds some build-related CDT actions to the menus and toolbars in |
| the Fortran perspective. |
| |
| \item In many cases, the XML describing a particular element in Photran |
| is essentially the same as the corresponding XML in CDT, except the |
| name and/or icon is changed. This is the case for, e.g., the |
| \textit{Local Fortran Application} launch configuration. |
| |
| \end{itemize} |
| |
| \item Many elements are reused through subclassing. For example, Photran's |
| \texttt{NewSourceFolderCreationWizard} subclasses an equivalent class in CDT |
| but overrides a method in order to change the title and icon for the wizard. |
| |
| \item As a last resort, some parts of Photran are copied from CDT and then |
| modified as necessary. This is the case with the |
| \texttt{FortranPerspectiveFactory} class, for example: There was no way to |
| accomplish the desired effect through subclassing (without modifying CDT), |
| so we (unfortunately) had to copy a class from CDT and then modify it |
| appropriately for Photran. |
| |
| \end{itemize} |
| |
| \section{The CDT Debugger and \texttt{gdb}} |
| |
| Currently, Photran re-uses the CDT debugger as-is and does not contribute any |
| enhancements to it. Here is a brief summary of how the debugger works: |
| |
| \begin{itemize} |
| |
| \item The so-called CDT debugger is actually just a graphical interface to |
| \texttt{gdb}, or more specifically to \texttt{gdb/mi}. So, if something doesn't |
| appear to work, it is advisable to try it in \texttt{gdb} directly or to use |
| another \texttt{gdb}-based tool such as DDD. |
| |
| \item The debugger UI ``contributes'' breakpoint markers and actions to the |
| editor. The ``set breakpoint'' action, and the breakpoint markers that appear in |
| the ruler of the CDT (and Photran) editors are handled \textbf{entirely} by the |
| CDT debug UI; there is no code for this in Photran. The ``set breakpoint'' |
| action is enabled by calling \lstinline!setRulerContextMenuId("#CEditorRulerContext");! |
| in the \texttt{AbstractFortranEditor} constructor. |
| |
| \item \texttt{gdb} reads debug symbols from the executable it is debugging. |
| That is how it knows what line it's on, what file to open, etc. Photran |
| has \textit{nothing} to do with this: These symbols are written entirely |
| by the compiler. Moreover, the compiler determines what shows up in the |
| Variables View. If the debugger views seem to be a mess, it is the |
| compiler's fault, not Photran's. |
| |
| \end{itemize} |