Source code repository for an CDT plug-in (Ecllipse)

Sat Nov 22 01:38:45 UTC 2008

Hi Daron and Sebastian,

Right now in plugin.xml, for the 1st 3 <extension>, the command of <run> tag is hard-coded to either 
i386-rtems4.9-gcc or i386-rtems4.9-g++. This might caused Sebastian's problem in openSuSE 10.3. 
RTEMS_TOOLSET only handles the customization for all other commands in the plugin.xml.

Here let me try to provide "documentation about the high-level structure/design/concepts of the plugin",
although it might not be exactly what Daron asked for.

I. Plugin Customization

The plugin can be customized in 4 levels (in the order of increasing difficulty):

1. Through environment variables such as RTEMS_TOOLSET, RTEMS_INSTALL_BSP_DIR, etc

    Either of your 2 proposals is better than the current one. Configuring through environment variables
    enabled me to do quick prototyping type of work.

2. Overriding default setting on project by project basis after a project is created. For example, adding
   more defined symbols via list box of defined symbols in compiler settings. During the development of
   the plugin, I tried to put all RTEMS specific options in "other flags" field of compiler and linker, and it
   worked for me.

3. Customize plugin.xml. Except settings provided by environment variables (e.g., RTEMS_TOOLSET),
    all default values are specified in plugin.xml, such as default C compiler command i386-rtems4.9-gcc.
    Also extensions are also specified in plugin.xml. Another example is the RTEMS specific setting page to
    enable/disable managers like barriers, console, etc)

4. Changing behavior via Java code. Element like <tool>, <option>, etc, provide hook to your specific
   Java class. The CDT builtin MinGW toolchain has about 4 such Java classes. We have 8 such Java
   classes (excluding Activator) in the initial verion.

II. The Hidden plugin.xml and Plug-in Inheritance

Besides RTEMS plugin.xml, there is actually an implicit or hidden plugin.xml, the plugin of CDT core.  For
your convenience I extract it and attached it to this email. 

CDT plugin.xml (parent) + RTEMS plugin.xml (child) ==> full definition of our plug-in

There is an inheritance relation between CDT plugin.xml (parent) + RTEMS plugin.xml (child). The 
inheritance provides the plugin foundation which is passed down by CDT core plugin.xml, and allow
us to customize or orverride some behaviors.

III. References

1. "Managed Build System Extensibility Document", came with CDT through menu Help | Help Contents | 
    CDT Plug-in Developer Guide | Programmer's Guide, or via  http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html

2. "What's New in CDT Build System 4.0", came with CDT through menu Help | Help Contents | 
    CDT Plug-in Developer Guide | Programmer's Guide.

3. (Mainly JTAG related) Using Open Source Tools for AT91SAM7S Cross Development, http://www.atmel.com/dyn/resources/prod_documents/atmel_tutorial_source.zip

IV. Reference Implementation of Eclipse/CDT Cross Development with Open Source Code

Before I started to code this plug-in, I found none of such open source implementations for reference.

Looking back, I think the MinGW or Cygwin toolchain bundled inside CDT can somehow be viewed
as a reference implentation with available open source code if you figure out how to seperate it from
the large body of CDT core code.

Now the initial version of RTEMS Eclipse Plug-in can be viewed as such an open source implementation.

V. The Outmost Layer 

In our plugin.xml, extension "org.rtems.cdt.toolchain"  at extension point 
"org.eclipse.cdt.managedbuilder.core.buildDefinitions" can be viewed as the outmost layer (excluding templates). 
It uses 3 other extensions  RtemsGccManagedMakePerProjectProfile/C/CPP, which provide scannerConfigDiscoveryProfile. 

VI Build Definition Model

The following is the UML model of elements of build definition model. It's extracted from #2 in the above reference.

The following is skeleton mapping of elements in the initial version to the above UML diagram.

projectType <===> <projectType id="cdt.managedbuild.target.gnu.rtems.exe" ...>
  which contains 
       2 configurations  <===> <configuration name="%RTEMS.Debug"> and <configuration name="%RTEMS.Release">
            each configuration contains ar, as, compiler, linker tools
                each tools contains inputType, outputType, option and optionCategory

In the following we briefly describe the main purpose of customization Java classes in the initial version.

At toolchain level, we have:

IsRtemsToolChainSupported.java -- determine if the RTEMS toolchain is supported

RtemsEnvironmentVariableSupplier.java 
RtemsScannerInfoCollector                  -- together provide auto-discovery of include, lib, bin paths

At tool level, we have:

RtemsCommandLineGenerator.java -- override default tool command based on RTEMS_TOOLSET
                                                  provide additional link objects for RTEMS managers

RtemsLinkCommandLineInfo.java    -- used by RtemsCommandLineGenerator.java

At option level:

RtemsBspDefinedSymbolsValueHandler.java  -- handles option of BSP predefined symbols
RtemsInstallBspDirectoryValueHandler.java   -- handles the -B search path option
RtemsManagerRelocationLinkHandler.java     -- handles the equivalent of MANAGERS/MANAGERS_NOT_WANTED in Makefile
I hope the above document helps.

Have a nice weekend too!

Robert Fu
> Date: Fri, 21 Nov 2008 13:21:21 -0600> From: joel.sherrill at oarcorp.com> To: daronchabot at gmail.com> CC: sebastian.huber at embedded-brains.de; robert.fu at live.com> Subject: Re: Source code repository for an CDT plug-in (Ecllipse)> > Please feel free to have these discussions on the mailing list.> I think doing so will draw more help in. > > Plus community activity level is a measure of project viability. :)> > I am thrilled this is all showing up. > > --joel> > Daron Chabot wrote:> > Sebastian Huber wrote:> > > >> Hi,> >>> >> I tried to get the plug-in from Robert running under my openSuSE 10.3> >> laptop, but it didn't work after two hours so I decided to start with an> >> empty plug-in for testing.> >> > > CVS access is working (at least read-access with the id/pswd I chose; > > haven't tried any commits yet). Thanks Joel & Jeff!> >> > Hmm... I very briefly reviewed the plugin and only changed two > > build-path settings to get it to build on my mac laptop.> >> > Plugin *functionality* is something that I have yet to explore fully. > > However, I was able to generate the template example. Building (i.e. > > Managed-Build make) the example did not work, but I wouldn't have > > expected it to... At least not without tweaking the plugin ;-)> >> > Robert: do you have any documentation about the high-level > > structure/design/concepts of the plugin? (UML, etc)> > > >> The plug-in from Robert was a valuable> >> information source. The scanner info collector profile turned out to be> >> a really nasty beast. It seems that the ID semantic is different from> >> all other IDs in CDT and the DefaultGCCScannerInfoCollector has some> >> undesired side-effects.> >> > >> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> > Would you please explain this comment more fully?> > > >> We should derive three toolchains ("RTEMS Toolchain (UNIX)", "RTEMS> >> Toolchain (Cygwin)" and "RTEMS Toolchain (Mingw)") from the general GCC> >> counterparts so we can re-use the CDT classes for path translation etc.> >> > >> > > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^> > This comment too, please.> > > >> The build options for a particular BSP can be derived via the standard> >> RTEMS make environment at project creation time. When a user creates a> >> project the following steps should be done:> >>> >> o Determine RTEMS toolchain installation path (e.g. /opt/rtems-4.10)> >> o Determine RTEMS version (e.g. 4.10)> >> o Determine RTEMS target (arm, powerpc, i368, ...)> >> > >> > >> > This is exactly why I suggested using the Preference Store extension > > point. Yes, the toolchain (& RTEMS) install location, RTEMS version, and > > target arch and BSP should be configurable per project but, it would be > > more convenient to have a user provide that information *once* (when > > they initially use the plugin) in a Preference Page. A New Project > > Wizard Page would then provide those stored settings (accessed > > Activator.getDefault().getPreferenceStore() ) from the preference store, > > as well as the ability to override them on a per-project basis.> >> > Either approach will alleviate the need for the RTEMS_TOOLSET, > > RTEMS_INSTALL_BSP_DIR, etc variables living in the user's environment. > > Or at least displace where those variable live...> > > >> Now we can derive all RTEMS tools like> >> ${RTEMS_TARGET}-rtems${RTEMS_VERSION}-gcc and adjust the PATH> >> environment variable if necessary.> >> > >> > >> > Exactly. That approach would permit the use of tools that don't have the > > RTEMS version info in their name (i.e. i386-rtems4.9-gcc versus > > i386-rtems-gcc): a blank RTEMS_VERSION string would still pickup the > > correct tool...> > > >> o Determine BSP makefile path (RTEMS_MAKEFILE_PATH). This path is> >> associated with exactly one BSP.> >>> >> Now we can query all the options (CFLAGS etc.) for the tools via a> >> special Makefile that is provided by the plug-in.> >>> >> The wizard fills now all build macros and tool options with the new values.> >>> >> > >> > > See suggestion above.> > > >> Have a nice weekend!> >> > >> > Indeed! Same to you all.> >> >> > -- dc> > > > > -- > Joel Sherrill, Ph.D. Director of Research & Development> joel.sherrill at OARcorp.com On-Line Applications Research> Ask me about RTEMS: a free RTOS Huntsville AL 35805> Support Available (256) 722-9985> > 
_________________________________________________________________
Windows Live Hotmail now works up to 70% faster.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20081121/61f2ab9a/attachment.html>