[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP/RDT and remote linuxtools
|
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
