[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP/RDT and remote linuxtools
|
Hi Wainer,
No estimated date on the prototype. I have it currently in a private
git branch. I have done the first part which was to indirectly
reference files and launching via a proxy. I still need to create the
extension and plug-in part so that RDT can be connected optionally.
I am also going to create a separate git branch where I directly use RDT
and avoid the need for a proxy. This is per the discussion with Greg
and Corey regarding that the RDT local base is light-weight and direct
access should be a better/cleaner design.
I then need to play with the RDT code to get an Autotools RDT project
wizard that will create a remote Autotools project.
There is no cross-compiling as it will follow the RDT model whereby the
project source resides on the remote system and the build is also done
on the remote system. Cross-compiling is a bit of a can of worms due to
the vast number of system setups you would need to be compatible with
(e.g. think platforms, tools, and installed libraries). It is much
cleaner and cheaper to keep the project remote and build on the system
it will ultimately run on.
This model differs from the Valgrind remote plug-in which currently
allows you to ship your executable just to a compatible remote system
and have it run and profiled there. Eventually, we would like to have
the user simply run Valgrind on a remote RDT project the same way it is
run locally (for the most part).
Regards,
-- Jeff J.
On 09/05/2011 10:11 AM, Wainer dos Santos Moschetta wrote:
Hi Jeff,
Do you have an estimated date for your remote Autotools first
release/prototype?
Does your design proposed necessarily implies on cross-compiling of
remote projects?
- Wainer
On 08/31/2011 03: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
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
