[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [linuxtools-dev] PTP and the Linux Tools Project support for remote build & launch
|
Hi Corey,
The remote story for linux-tools isn't complete yet and is evolving so
it's great to have your testing/feedback.
We have started with a basic model whereby an end-user develops locally
and runs their
executable on the remote system for profiling purposes but that isn't
the end goal. Initially, we started with TCF then migrated to use RSE.
Building on the remote system is definitely something we see as
necessary as cross-tooling is difficult when you consider all the
libraries that may be needed plus differences in tooling. PTP has been
on our radar to explore.
The PTP model or more specifically, the RDT (Remote Development Tools)
model is one whereby the source-code is always kept on the remote system
and then build/run/debug is performed there as well. This accomodates
the user that wants to use Eclipse on a local system with a remote
target (e.g. run Eclipse on Windows and develop for Linux) and we have
seen requests for this. This model can also be used to accomodate a
cloud user, but there is a cost issue due to the fact that data must be
preserved across cloud accesses since the project resides there and
usually there is a charge associated with this (e.g. Amazon EC2).
It isn't clear from the presentation you specified below whether Team
support is provided whereby a user can check-out code directly to the
remote system via CVS, SVN, or Git and have the project be treated as a
remote project (e.g. check out gdb sources and make it a remote C/C++
project). I would be interested in modifying the Autotools plug-in to
support remote projects if this if it can be done reasonably and without
dragging in too much in the way of requirements.
Now, that all said, it would be desirable to enhance the launch support
to allow running the Linux profiling tools on such remote projects. I
would envision it such that the end-user sees the normal profiling
launch dialogs but the data there pertains to the remote project (i.e.
handled transparently). I'm not inclined to also want to have a generic
remote profiling launch such that you specify some arbitrary remote
system and an arbitrary executable you know to be there as I think you
were attempting to do. Right-click profiling on an executable would
work on the remote project as it does for current projects. I would
want to see that the normal profiling launch does not require PTP. Does
that seem reasonable to you or is it impossible to do this transparently?
There is one other model I would also like to see addressed. That is,
local development
and remote build/test. This would be a user that wishes to develop
without a remote
connection and later wants to build/run/test on a remote system such as
a cloud instance. If PTP can convert an existing project to a remote
one, that would be one solution, although this could result in
modifying multiple copies of the code (local/remote) so it would be
preferred to create a remote project that accesses the local files
though this may add a performance hit.
Regards,
-- Jeff J.
On 07/27/2011 09:53 PM, Corey Ashford wrote:
Hi,
I had a brief discussion today with Jeff Johnston on the IRC channel
today. I had been experimenting with the new Valgrind support for
remote launch via RSE connections. I ran into a strange problem and it
turned out to be because I had misunderstood the intent of the remote
launch capability, that it is designed for a "cross-compile/link,
download executable, remote launch Valgrind" workflow, rather than a
"remote build, remote launch Valgrind" workflow. Knowing this allowed
me to understand why the dialogs didn't allow me to choose an executable
residing on the remote machine.
To take a quick step back, we in IBM toolchain team are wanting to use
remote Valgrind launches in the "remote build, remote launch" workflow.
The Eclipse PTP project already has some nice support for remote builds,
remote launch, and remote debug (though remote debug requires an
intermediary process called SDM). The usability of PTP connections, in
my opinion, is much cleaner than that of RSE. RSE requires manually
starting the RSE server on the remote machine, opening holes in the
firewall, etc. PTP uses ssh connections to communicate with its
dynamically downloaded java-based dstore daemon. All of its
communication goes through ssh, so no firewall hole poking is needed.
What is needed on the remote side is to install Java and sdm (sdm is
needed only for debugging).
One thing I didn't mention about setting up PTP, is that in order to
launch a remote executable, debug, profile, etc., you need to start up a
"Resource Manager". Fortunately this is easy to do. There are a number
of Resource Manager types to choose from, and the generic "Remote
Launch" resource manager works just fine for single remote host setups.
What do you think of utilizing PTP for adding remote build, remote
launch capability to the Linux Tools Project plug-ins? There's been a
lot of work and refinement that's gone into PTP over the years, and I
think Linux Tools could benefit from it. We could structure it so that
the remote build, remote launch are separate features that people
wouldn't have to install, if they didn't want to install PTP when they
install Linux Tools.
If you haven't played with PTP before, there's a nice tutorial here:
http://download.eclipse.org/tools/ptp/docs/ptp-sc10-tutorial.pdf
- Corey
_______________________________________________
linuxtools-dev mailing list
linuxtools-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
