Re: [linuxtools-dev] PTP/RDT and remote linuxtools

[Jeff Johnston <jjohnstn@xxxxxxxxxx>]

Hi Greg,

I understand your frustration, but we want to keep things simple.  For 
the majority of our users who just want to run things locally, there is 
no need to require PTP/RDT/RSE and whatever these drag in.

You need to understand that we maintain Linux Tools projects in Fedora 
as well.  If Autotools now requires PTP/RDT, then it needs to be 
packaged/maintained with all of its dependencies. I don't want to have 
to package PTP today for regular Autotools usage which works fine as-is, 
but I would like to make Autotools support RDT.  I also don't want to 
duplicate the code to make RDT versions.

It's simply a way to disconnect the requirement, allow code reuse, and 
allow the end-user to ultimately decide if remote capability should be 
installed.

Does your framework work in a similar way?  i.e. do you have a very 
small default case plug-in which handles the local case and based on the 
project will attempt to load extensions to handle the more complex 
remote project scenario?

Regards,

-- Jeff J.

On 08/31/2011 02:38 PM, Greg Watson wrote:
> Sigh.
>
> The PTP org.eclipse.ptp.remote.* plugins are supposed to do exactly this. Provide a set of interfaces that work the same for local or remote. You can then plug in support for different remote service providers, include RSE and Remote Tools (part of PTP) and Local. It's a shame to see yet another implementation.
>
> Also, we provide a framework for integrating tools, particularly performance tools, called ETFw. It saves you having to write any code at all. You can just provide an XML description of the tool command, as well as specify SWT widgets that are displayed on the profile configuration dialog. I believe there is already a valgrind tool description. You might want to take a look at this also.
>
> Regards,
> Greg
>
>
> On Aug 31, 2011, at 2:09 PM, Jeff Johnston wrote:
>
> > Hi Corey,
> >
> > I am currently working on a File and Launch proxy for Autotools which might help here.
> >
> > The idea was that I wanted to make the Autotools plug-in RDT-able without actually having a dependency on RDT and PTP.  Thus, a future RDT Autotools project would for the most part work the same as a local one.
> >
> > The file accesses in Autotools are changed to use the File proxy which is doled out by a Manager based on the project.  Currently, this always doles out a local proxy but for an RDT project, it would look for an extension to supply the proxy for RDT.  This extension would be in a separate autotools-rdt plug-in that isn't required by the main plug-ins.
> >
> > Thus, the Autotools plug-in doesn't ultimately care whether the project is remote or local.  It accesses and creates files as normal, through the proxy.
> >
> > Similarly, there would be a launch proxy for executing commands.  The local one would use the current CDT launcher classes and for RDT, it would use the appropriate RDT services.
> >
> > I am thinking that if the proxy managers were moved to a separate plug-in that could be shared, Valgrind could also use it.  Then, the local Valgrind launch could be unified to work with an RDT project or local project.  The remote Valgrind would still be a separate animal as it is today.
> >
> > Thoughts?
> >
> > -- Jeff J.
> >
> > On 08/30/2011 07:48 PM, Corey Ashford wrote:
> > > Hey folks,
> > >
> > > I have a prototype launcher for Valgrind working over PTP's Remote
> > > Development Tools API.  I basically welded/hacked some code from the
> > > AbstractParallelLaunchDelegate into the
> > > org.eclipse.linuxtools.profiling.remote.RemoteConnection package.
> > >
> > > Then I used some tabs from the Parallel Application launcher, the
> > > Valgrind tab from linux tools, and then adapted the launch code to do
> > > something very similar to what was done in
> > > org.eclipse.linuxtools.valgrind.launch.remote.
> > >
> > > I have it working, but I'm not really sure what to do with it as far as
> > > getting it into a state where you folks could commit it, because I don't
> > > want to break the existing RSE-based code.
> > >
> > > One thought would be that since RDT is a layer on top of RSE *or*
> > > RemoteTools, we could just replace the existing Valgrind launcher with
> > > my new one.
> > >
> > > The Application Tab in the launcher assumes that the executable was
> > > built on the remote machine, and so it provides a file chooser for
> > > choosing an executable on the remote machine.  You can choose to
> > > download a locally-built executable, though, and there is a local file
> > > chooser for that option.
> > >
> > > Do you have some ideas about how we might move forward with this?
> > >
> > > - Corey