plugin first steps

Sat Nov 22 21:09:45 UTC 2008

Hi Daron,

You're right, the osList was hardcoded to "win32" in the plugin.xml.

Thanks,
Robert Fu

---------------------------------

<toolChain
id="cdt.managedbuild.toolchain.gnu.rtems.base"
name="RTEMS Toolchain"
archList="all"
osList="win32"
configurationEnvironmentSupplier="org.rtems.cdt.toolchain.RtemsEnvironmentVariableSupplier"
isToolChainSupported="org.rtems.cdt.toolchain.IsRtemsToolChainSupported"
scannerConfigDiscoveryProfileId="org.rtems.cdt.toolchain.RtemsGccManagedMakePerProjectProfile"
targetTool="cdt.managedbuild.tool.gnu.cpp.linker.rtems.base;cdt.managedbuild.tool.gnu.c.linker.rtems.base;cdt.managedbuild.tool.gnu.archiver">

<targetPlatform
id="cdt.managedbuild.target.gnu.platform.rtems.base"
name="Target Platform RTEMS"
binaryParser="org.eclipse.cdt.core.PE" 
osList="win32" 
archList="all">
</targetPlatform>
> From: daronchabot at gmail.com> Subject: Re: plugin first steps> Date: Sat, 22 Nov 2008 15:00:37 -0600> To: robert.fu at live.com> CC: sebastian.huber at embedded-brains.de; rtems-users at rtems.org> > > On 22-Nov-08, at 2:40 PM, Robert Fu wrote:> > > Hi Daron,> >> > > 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.> >> > Agreed. I also thought about whether we need support "Standard > > Makefile"> > type of project.> >> > Beside the CVS repo you mentioned earlier, the official CDT release > > also come> > with CDT source code, and being able to browsing and debugging/ > > tracing into> > CDT source code helped me in the development.> >> > If you and Sebastian send me the error messages, commands invoked and> > the Makefile generated for the HelloWorld example on your system > > (via private> > email, not the whole list), perhaps I can better understand what > > problems> > you're currently facing on your system.> > Sure. But, I think most of the problems I've seen are due to hard- > coded command-names and supported-OS types.> > I'm making some notes as I go, so I'll report back later when I've > found out more. Probably tonight or tomorrow...> > > >> > > From: daronchabot at gmail.com> > > Subject: Re: plugin first steps> > > Date: Sat, 22 Nov 2008 13:16:49 -0600> > > To: robert.fu at live.com> > > CC: sebastian.huber at embedded-brains.de; rtems-users at rtems.org> > >> > >> > > 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.> > >> > > _______________________________________________> > > rtems-users mailing list> > > rtems-users at rtems.com> > > http://rtems.rtems.org/mailman/listinfo/rtems-users> >> >> > Proud to be a PC? Show the world. Download the “I’m a PC” Messenger > > themepack now. Download now.> > _______________________________________________> rtems-users mailing list> rtems-users at rtems.com> http://rtems.rtems.org/mailman/listinfo/rtems-users
_________________________________________________________________
Color coding for safety: Windows Live Hotmail alerts you to suspicious email.
http://windowslive.com/Explore/Hotmail?ocid=TXT_TAGLM_WL_hotmail_acq_safety_112008 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20081122/ad62b4c9/attachment.html>