RE: [cdt-dev] Re: [dsdp-tm-dev] Moving the RSE "Remote CDTLaunch"feature

["Oberhuber, Martin" <Martin.Oberhuber@xxxxxxxxxxxxx>]

PS 
 
In order to make the build work with RSE, I think the simplest solution would be if the builder just does this when bootstrapping:

*	
	download + extract base platform (eclipse platform or SDK)
*	
	download + extract RSE-runtime-Mx.zip

Building against this platform will then be easy. It would be up to you whether you'd always want to build against RSE 3.0 (Ganymede), or against RSE M(-1) -- the milestone before the current one -- or any recent I-build. Each approach should work fine.
 
Of course you could also provision your target platform with p2 if you prefer that. Whatever you think is easiest :-)
 
Cheers,
--
Martin Oberhuber, Senior Member of Technical Staff, Wind River
Target Management Project Lead, DSDP PMC Member
http://www.eclipse.org/dsdp/tm
 
 


________________________________

	From: dsdp-tm-dev-bounces@xxxxxxxxxxx [mailto:dsdp-tm-dev-bounces@xxxxxxxxxxx] On Behalf Of Oberhuber, Martin
	Sent: Mittwoch, 04. März 2009 23:33
	To: CDT General developers list.; Target Management developer discussions
	Subject: RE: [cdt-dev] Re: [dsdp-tm-dev] Moving the RSE "Remote CDTLaunch"feature into CDT
	
	
	
	TM used to be +2 because of consuming internal non-API in remoteCDT.
	 
	When the remoteCDT plugin is in CDT, then TM can go +1 easily.
	 
	I believe that CDT can remain at +1 because the reverse dependency (remoteCDT --> RSE) only consumes public API which is not subject to change.
	So we should be able to build at the same time.
	 
	HTH,
	--
	Martin Oberhuber, Senior Member of Technical Staff, Wind River
	Target Management Project Lead, DSDP PMC Member
	http://www.eclipse.org/dsdp/tm
	 
	 


________________________________

		From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Chris Recoskie
		Sent: Mittwoch, 04. März 2009 22:22
		To: Target Management developer discussions
		Cc: Target Management developer discussions; CDT General developers list.; dsdp-tm-dev-bounces@xxxxxxxxxxx
		Subject: [cdt-dev] Re: [dsdp-tm-dev] Moving the RSE "Remote CDT Launch"feature into CDT
		
		

		Hmm.... Yeah... then CDT would have to go from a +1 Galileo project to a +3? Unless TM decided to move up to +1?
		
		Sounds messy, at least for right now.
		
		===========================
		Chris Recoskie
		Team Lead, IBM CDT and RDT
		IBM Toronto
		 Pawel Piech <pawel.piech@xxxxxxxxxxxxx>
		
		
		

				Pawel Piech <pawel.piech@xxxxxxxxxxxxx> 
				Sent by: dsdp-tm-dev-bounces@xxxxxxxxxxx 

				03/04/2009 04:05 PM 
	
	Please respond to
Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>

 

To

Target Management developer discussions <dsdp-tm-dev@xxxxxxxxxxx>, "CDT General developers list." <cdt-dev@xxxxxxxxxxx>	


cc

	


Subject

Re: [dsdp-tm-dev] Moving the RSE "Remote CDT Launch" feature into CDT	
	 	

		I like the idea of having the RSE-based remote launch in CDT, but it would introduce a dependency from CDT on the Target Management project, which would have implications on the CDT build.
		-Pawel
		
		Oberhuber, Martin wrote: 

				Hi all,
				
				As some of you may know, one part of the TM / RSE offering is a "Remote CDT" Launch configuration, which allows 

					*	Uploading files through RSE-provided Services 
					*	Launching the program remotely through an RSE-provided shell 
					*	Debugging remotely through a remote gdbserver instance (requires local cross-gdb).

				The implementation of this feature requires using CDT internal non-API [1] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=257402>  in order to get the debugger configuration page into the launch config UI, which is forbidden in Galileo.
				
				We'd therefore think it makes sense to move the feature into the CDT [2] <https://bugs.eclipse.org/bugs/show_bug.cgi?id=267065>  -- on the RSE side, only public API is being used. In other words, we propose adding a new optional CDT feature "Remote Launch" which depends on the RSE, and removing that feature from the RSE offering.
				
				The feature itself doesn't expose any API (everything is "internal"), so renaming the plugin and/or the package should not be an issue if that is desired.
				
				Does the CDT Community agree that this is a good thing to do?
				Who is the right person to get in touch with for making it happen?
				Is it realistic to get that done for M6?
				
				[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=257402 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=257402> 
				[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=267065 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=267065> 
				
				Thanks,
				--
				Martin Oberhuber, Senior Member of Technical Staff, Wind River
				Target Management Project Lead, DSDP PMC Member
				http://www.eclipse.org/dsdp/tm <http://www.eclipse.org/dsdp/tm> 
				
				
				
				
________________________________

				
				_______________________________________________
				dsdp-tm-dev mailing list
				dsdp-tm-dev@xxxxxxxxxxx <mailto:dsdp-tm-dev@xxxxxxxxxxx> 
				https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev <https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev> 
				 

		_______________________________________________
		dsdp-tm-dev mailing list
		dsdp-tm-dev@xxxxxxxxxxx
		https://dev.eclipse.org/mailman/listinfo/dsdp-tm-dev