plugin first steps

Sat Nov 22 19:16:49 UTC 2008

On 22-Nov-08, at 3:38 AM, Robert Fu wrote:

> For the "first steps" type of references, there is also another  
> place contains
> more detailed information: "Managed Build System Extensibility  
> Document"
> (mentioned in referrence section in my previous email) contains a  
> section called
> "Tutorial: An Example Tool Integration". It worked well for me. The  
> initial
> version of the plug-in was built upon what I got after following  
> the tutorial
> step by step.
>
> Somebody said "Managed Build System Extensibility Document" is the  
> bible
> for CDT plug-in development, and I believed it. In fact this  
> document plus
> "What's New in CDT Build System 4.0" are the only 2 documents that
> guided me for the developement of initial RTEMS plug-in.

Yah, I've been through the "MBS Extensibility" doc, and it *is* the  
"bible" for CDT plugin development. But, there are other good sources  
too, the CDT sources being an example. Another is the CDT extension  
point reference docs:

	http://help.eclipse.org/help33/index.jsp?topic=/ 
org.eclipse.cdt.doc.isv/reference/extension-points/index.html

Although these refer to eclipse 3.3, they are still very much  
relevant to the CDT as found in eclipse 3.4.

> Although I don't know how actually Sebastian plan to do it, I think  
> if we can
> automatically extract settings/configurations from Makefiles generated
> by configure process, it's an improvement over the current one  
> since it'd
> require less user input.

That approach implies some type of parser is required. I'm sure  
Sebastian will communicate his ideas here as soon as he's able.

Only a couple of years ago, the CDT had two types of projects:  
Managed Build and Standard Makefile. Both are still present, only in  
a more refined form. Managed build projects construct Makefiles  
automatically, while Standard Makefile projects simply rely on the  
user to provide a (Makefile-based) build system.

The RTEMS-Eclipse plugin I was designing would utilize the RTEMS  
makefile templates, Makefile.leaf, Makefile.lib, and Makefile.dir  
(found in ${RTEMS_INSTALL_LOCATION}/make/Templates), *in conjuction*  
with user-provided values like executable name, etc.

However, upon closer analysis, it became clear that in order to  
maintain a useful degree of independence from the RTEMS build-system  
and maximum flexibility, the Managed Build approach is *the* way to go.

> One other improvement I can see is to make it work on Linux and Mac.
> It seems we 3 have right mix of environments: I have Windows one,  
> Sebastian
> has openSuSE 10.3 env and you have Mac env.

Having the plugin work across the 3, main OSes is not just an  
improvement, it's a *necessity * :-)

Of course, we should strive for OS-independence as much as possible...

I would also lump RTEMS target arch and BSP selection as necessities.

> I assume that we cannot get all we want in one shot, so one of many  
> possible
> ways to move forward is:
>
> 1. Make the 1st version work in Linux and Mac; Once it works in one  
> OS, re-test
>     it in the other OS until we get one version that works in each  
> of the 3 OS. We
>     then use it as a comman base for further refinement.
>
> 2. Add new improvements one by one. After one new feature works in  
> one OS,
>     re-test the new plug-in in the other OS. We go through this  
> iterative process
>     until we think we have all necessary features.

Yes. An iterative development scheme is the only way to go.

We need to get a solid base to build upon. First focusing on the  
basic toolchain elements: assembler, c/c++ compiler & linker,  
archiver. Debugger and Launch configs are almost as important. But we  
have to be able to build something to run and debug first :-)

I'm still studying your plugin trying to get up to speed... thanks  
again.

>
>
> > From: daronchabot at gmail.com
> > Subject: plugin first steps
> > Date: Fri, 21 Nov 2008 21:05:17 -0600
> > To: robert.fu at live.com
> > CC: sebastian.huber at embedded-brains.de; rtems-users at rtems.org
> >
> > Robert,
> >
> > Thanks for your contribution. It looks like a good place to start.
> >
> > I sent the link below to Sebastian in an earlier email.
> >
> > If you have not already done so, I recommend checking out the cdt- 
> all
> > CVS module from the Eclipse repo. You can find directions here:
> >
> > http://wiki.eclipse.org/Getting_started_with_CDT_development
> >
> > The best place to learn how things work is the reference
> > implementations contained in the "cdt-all" CVS module.
> >
> > If you and Sebastian have no objections, I'd like to remove the
> > unused library dependencies from the plugin's ".settings" file,
> > partly to see if I can commit to the RTEMS cvs repo and partly to
> > clean things up a bit.
> >
> > Those dependencies are:
> > 1) org.eclipse.cdt.core.lrparser_5.0.1.200809120802.jar
> > 2) org.eclipse.cdt.core.parser.upc_5.0.0.200809120802.jar
> >
> >
> > -- dc
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-us
>
> Get more done, have more fun, and stay more connected with Windows  
> Mobile®. See how.