<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
font-size: 10pt;
font-family:Verdana
}
</style>
</head>
<body class='hmmessage'>
Hi Daron and Sebastian,<BR>
<BR>
Right now in plugin.xml, for the 1st 3 <extension>, the command of <run> tag is hard-coded to either <BR>
i386-rtems4.9-gcc or i386-rtems4.9-g++. This might caused Sebastian's problem in openSuSE 10.3. <BR>
RTEMS_TOOLSET only handles the customization for all other commands in the plugin.xml.<BR>
<BR>
Here let me try to provide "documentation about the high-level structure/design/concepts of the plugin",<BR>
although it might not be exactly what Daron asked for.<BR>
<BR>
<BR>
I. Plugin Customization<BR>
<BR>
The plugin can be customized in 4 levels (in the order of increasing difficulty):<BR>
<BR>
1. Through environment variables such as RTEMS_TOOLSET, RTEMS_INSTALL_BSP_DIR, etc<BR>
<BR>
Either of your 2 proposals is better than the current one. Configuring through environment variables<BR>
enabled me to do quick prototyping type of work.<BR>
<BR>
2. Overriding default setting on project by project basis after a project is created. For example, adding<BR>
more defined symbols via list box of defined symbols in compiler settings. During the development of<BR>
the plugin, I tried to put all RTEMS specific options in "other flags" field of compiler and linker, and it<BR>
worked for me.<BR>
<BR>
3. Customize plugin.xml. Except settings provided by environment variables (e.g., RTEMS_TOOLSET),<BR>
all default values are specified in plugin.xml, such as default C compiler command i386-rtems4.9-gcc.<BR>
Also extensions are also specified in plugin.xml. Another example is the RTEMS specific setting page to<BR>
enable/disable managers like barriers, console, etc)<BR>
<BR>
4. Changing behavior via Java code. Element like <tool>, <option>, etc, provide hook to your specific<BR>
Java class. The CDT builtin MinGW toolchain has about 4 such Java classes. We have 8 such Java<BR>
classes (excluding Activator) in the initial verion.<BR>
<BR>
<BR>
II. The Hidden plugin.xml and Plug-in Inheritance<BR>
<BR>
Besides RTEMS plugin.xml, there is actually an implicit or hidden plugin.xml, the plugin of CDT core. For<BR>
your convenience I extract it and attached it to this email. <BR>
<BR>
CDT plugin.xml (parent) + RTEMS plugin.xml (child) ==> full definition of our plug-in<BR>
<BR>
There is an inheritance relation between CDT plugin.xml (parent) + RTEMS plugin.xml (child). The <BR>
inheritance provides the plugin foundation which is passed down by CDT core plugin.xml, and allow<BR>
us to customize or orverride some behaviors.<BR>
<BR>
III. References<BR>
<BR>
1. "Managed Build System Extensibility Document", came with CDT through menu Help | Help Contents | <BR>
CDT Plug-in Developer Guide | Programmer's Guide, or via <A href="http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html">http://help.eclipse.org/help33/index.jsp?topic=/org.eclipse.cdt.doc.isv/guide/mbs/extensibilityGuide/Managed_Build_Extensibility.html</A><BR>
<BR>
2. "What's New in CDT Build System 4.0", came with CDT through menu Help | Help Contents | <BR>
CDT Plug-in Developer Guide | Programmer's Guide.<BR>
<BR>
3. (Mainly JTAG related) Using Open Source Tools for AT91SAM7S Cross Development, <A href="http://www.atmel.com/dyn/resources/prod_documents/atmel_tutorial_source.zip">http://www.atmel.com/dyn/resources/prod_documents/atmel_tutorial_source.zip</A><BR>
<BR>
<BR>IV. Reference Implementation of Eclipse/CDT Cross Development with Open Source Code<BR>
<BR>
Before I started to code this plug-in, I found none of such open source implementations for reference.<BR>
<BR>
Looking back, I think the MinGW or Cygwin toolchain bundled inside CDT can somehow be viewed<BR>
as a reference implentation with available open source code if you figure out how to seperate it from<BR>
the large body of CDT core code.<BR>
<BR>
Now the initial version of RTEMS Eclipse Plug-in can be viewed as such an open source implementation.<BR>
<BR>
V. The Outmost Layer <BR>
<BR>
In our plugin.xml, extension "org.rtems.cdt.toolchain" at extension point <BR>
"org.eclipse.cdt.managedbuilder.core.buildDefinitions" can be viewed as the outmost layer (excluding templates). <BR>
It uses 3 other extensions RtemsGccManagedMakePerProjectProfile/C/CPP, which provide scannerConfigDiscoveryProfile. <BR>
<BR>
VI Build Definition Model<BR>
<BR>
The following is the UML model of elements of build definition model. It's extracted from #2 in the above reference.<BR>
<BR>
<P class=MsoNormal style="MARGIN-TOP: 6pt"><IMG src="http://127.0.0.1:4334/help/topic/org.eclipse.cdt.doc.isv/guide/cdt_build_system/whats_new/4.0/whats_1.gif" border=0></P>
<BR>
The following is skeleton mapping of elements in the initial version to the above UML diagram.<BR>
<BR>
projectType <===> <projectType id="cdt.managedbuild.target.gnu.rtems.exe" ...><BR>
which contains <BR>
2 configurations <===> <configuration name="%RTEMS.Debug"> and <configuration name="%RTEMS.Release"><BR>
each configuration contains ar, as, compiler, linker tools<BR>
each tools contains inputType, outputType, option and optionCategory<BR>
<BR>
In the following we briefly describe the main purpose of customization Java classes in the initial version.<BR>
<BR>
At toolchain level, we have:<BR>
<BR>
IsRtemsToolChainSupported.java -- determine if the RTEMS toolchain is supported<BR>
<BR>
RtemsEnvironmentVariableSupplier.java <BR>
RtemsScannerInfoCollector -- together provide auto-discovery of include, lib, bin paths<BR>
<BR>
At tool level, we have:<BR>
<BR>
RtemsCommandLineGenerator.java -- override default tool command based on RTEMS_TOOLSET<BR>
provide additional link objects for RTEMS managers<BR>
<BR>
RtemsLinkCommandLineInfo.java -- used by RtemsCommandLineGenerator.java<BR>
<BR>
At option level:<BR>
<BR>
RtemsBspDefinedSymbolsValueHandler.java -- handles option of BSP predefined symbols<BR>
RtemsInstallBspDirectoryValueHandler.java -- handles the -B search path option<BR>
RtemsManagerRelocationLinkHandler.java -- handles the equivalent of MANAGERS/MANAGERS_NOT_WANTED in Makefile<BR>
<BR>I hope the above document helps.<BR>
<BR>
Have a nice weekend too!<BR>
<BR>
Robert Fu<BR>
<BR><BR>> Date: Fri, 21 Nov 2008 13:21:21 -0600<BR>> From: joel.sherrill@oarcorp.com<BR>> To: daronchabot@gmail.com<BR>> CC: sebastian.huber@embedded-brains.de; robert.fu@live.com<BR>> Subject: Re: Source code repository for an CDT plug-in (Ecllipse)<BR>> <BR>> Please feel free to have these discussions on the mailing list.<BR>> I think doing so will draw more help in. <BR>> <BR>> Plus community activity level is a measure of project viability. :)<BR>> <BR>> I am thrilled this is all showing up. <BR>> <BR>> --joel<BR>> <BR>> Daron Chabot wrote:<BR>> > Sebastian Huber wrote:<BR>> > <BR>> >> Hi,<BR>> >><BR>> >> I tried to get the plug-in from Robert running under my openSuSE 10.3<BR>> >> laptop, but it didn't work after two hours so I decided to start with an<BR>> >> empty plug-in for testing.<BR>> >> <BR>> > CVS access is working (at least read-access with the id/pswd I chose; <BR>> > haven't tried any commits yet). Thanks Joel & Jeff!<BR>> ><BR>> > Hmm... I very briefly reviewed the plugin and only changed two <BR>> > build-path settings to get it to build on my mac laptop.<BR>> ><BR>> > Plugin *functionality* is something that I have yet to explore fully. <BR>> > However, I was able to generate the template example. Building (i.e. <BR>> > Managed-Build make) the example did not work, but I wouldn't have <BR>> > expected it to... At least not without tweaking the plugin ;-)<BR>> ><BR>> > Robert: do you have any documentation about the high-level <BR>> > structure/design/concepts of the plugin? (UML, etc)<BR>> > <BR>> >> The plug-in from Robert was a valuable<BR>> >> information source. The scanner info collector profile turned out to be<BR>> >> a really nasty beast. It seems that the ID semantic is different from<BR>> >> all other IDs in CDT and the DefaultGCCScannerInfoCollector has some<BR>> >> undesired side-effects.<BR>> >> <BR>> >> <BR>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>> > Would you please explain this comment more fully?<BR>> > <BR>> >> We should derive three toolchains ("RTEMS Toolchain (UNIX)", "RTEMS<BR>> >> Toolchain (Cygwin)" and "RTEMS Toolchain (Mingw)") from the general GCC<BR>> >> counterparts so we can re-use the CDT classes for path translation etc.<BR>> >> <BR>> >> <BR>> > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<BR>> > This comment too, please.<BR>> > <BR>> >> The build options for a particular BSP can be derived via the standard<BR>> >> RTEMS make environment at project creation time. When a user creates a<BR>> >> project the following steps should be done:<BR>> >><BR>> >> o Determine RTEMS toolchain installation path (e.g. /opt/rtems-4.10)<BR>> >> o Determine RTEMS version (e.g. 4.10)<BR>> >> o Determine RTEMS target (arm, powerpc, i368, ...)<BR>> >> <BR>> >> <BR>> ><BR>> > This is exactly why I suggested using the Preference Store extension <BR>> > point. Yes, the toolchain (& RTEMS) install location, RTEMS version, and <BR>> > target arch and BSP should be configurable per project but, it would be <BR>> > more convenient to have a user provide that information *once* (when <BR>> > they initially use the plugin) in a Preference Page. A New Project <BR>> > Wizard Page would then provide those stored settings (accessed <BR>> > Activator.getDefault().getPreferenceStore() ) from the preference store, <BR>> > as well as the ability to override them on a per-project basis.<BR>> ><BR>> > Either approach will alleviate the need for the RTEMS_TOOLSET, <BR>> > RTEMS_INSTALL_BSP_DIR, etc variables living in the user's environment. <BR>> > Or at least displace where those variable live...<BR>> > <BR>> >> Now we can derive all RTEMS tools like<BR>> >> ${RTEMS_TARGET}-rtems${RTEMS_VERSION}-gcc and adjust the PATH<BR>> >> environment variable if necessary.<BR>> >> <BR>> >> <BR>> ><BR>> > Exactly. That approach would permit the use of tools that don't have the <BR>> > RTEMS version info in their name (i.e. i386-rtems4.9-gcc versus <BR>> > i386-rtems-gcc): a blank RTEMS_VERSION string would still pickup the <BR>> > correct tool...<BR>> > <BR>> >> o Determine BSP makefile path (RTEMS_MAKEFILE_PATH). This path is<BR>> >> associated with exactly one BSP.<BR>> >><BR>> >> Now we can query all the options (CFLAGS etc.) for the tools via a<BR>> >> special Makefile that is provided by the plug-in.<BR>> >><BR>> >> The wizard fills now all build macros and tool options with the new values.<BR>> >><BR>> >> <BR>> >> <BR>> > See suggestion above.<BR>> > <BR>> >> Have a nice weekend!<BR>> >> <BR>> ><BR>> > Indeed! Same to you all.<BR>> ><BR>> ><BR>> > -- dc<BR>> > <BR>> <BR>> <BR>> -- <BR>> Joel Sherrill, Ph.D. Director of Research & Development<BR>> joel.sherrill@OARcorp.com On-Line Applications Research<BR>> Ask me about RTEMS: a free RTOS Huntsville AL 35805<BR>> Support Available (256) 722-9985<BR>> <BR>> <BR><BR><br /><hr />Windows Live Hotmail now works up to 70% faster. <a href='http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_faster_112008' target='_new'>Sign up today.</a></body>
</html>