Re: [linuxtools-dev] PTP and the Linux Tools Project support for remote

[Corey Ashford <cjashfor@xxxxxxxxxxxxxxxxxx>]

On 07/28/2011 10:47 AM, Jeff Johnston wrote:
> 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.

The issue of making remote shared libraries available on the local
machine also raises legal concerns as well as technical ones.

On top of that, there's also the issue of include files to deal with.

>  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.

Very similar in our case: our initial build will be Linux client
(laptop/workstation etc) to Linux remote host.

>  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).

That's a good question.  I haven't tried that.  It's limited in the sort
of projects you can create at this moment as well.  For example, you
cannot yet create Managed C/C++ projects; the projects are required to
have hand-managed Makefiles.  This works fine for working with existing
code bases, though.  I don't know if Managed C/C++ projects are in the
works or not.

I have done things like check out the Linux kernel code from a git tree
on the remote host, and then accessed it using PTP.  That works fine.
However managing the remote Git tree is another story.  I just used
command git (or gitk / git gui) on the remote machine to do my git
operations.

They also have another mechanism you can use, but is still in incubation
- Synchronized Projects.  It *uses* git to maintain a local source tree
and a remote source tree.  Every time you edit a file and do a save, it
creates a small commit, and pushes that commit to the remote tree.  They
are working on modifying it so that it uses a separate branch for these
micro-commits, but when I tried it out, it used the master branch for
them.  This would help it to play nicely with existing git-based
projects.  As for CVS and SVN, I don't think there are any plans to use
those, though I think you could use this git mechanism *on top of*
SVN/CVS/etc without interfering with the underlying SCM metadata.

When I evaluated Synchronized Projects a couple of months ago, I decided
that it was not yet suitable for our purposes, mainly because of the git
branch mechanism, but also because remotely-built resources, such as
executables and auto-generated code, do not show up in the local view.
This is because the synchronization mechanism only works in one
direction: from local to remote, and not the other way around.

This makes launching profiles, debug sessions, etc. much more difficult.

> 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.

Yes, that's something that would be very nice, especially for working
with OSS.

> 
> 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).

That would be ideal.  I'm not really that wild about the whole launch
config mechanism as it is today, but I can see how they arrived there.

One problem is that because executables are not recognized as such when
they are in remote projects, the context menu doesn't know that you can
launch a profile on the executable object.

  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 agree.  I was confused when I launched the remote Valgrind launch.  I
didn't understand why it didn't fill in the executable name for me, ...
it should know based on my right-click.

The reason that executables are not recognized as such is because of
performance issues of scanning the remote machine for executables.  But
it seems we need some sort of better solution than just to wave it off
as unworkable.


>  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?

That seems reasonable to me, though I'm pretty new to Eclipse plug-in
programming.

I would think that the launch code could know what sort of project that
the executable resides in, and then construct whatever tabs and default
values that are needed to do the launch, without the user having to
change anything.  In particular, I would think that it could find out
which RDT connection is being used for the project containing the
executable.

This would mean, I suppose, that profiling would have to understand RDT
and RSE connections, and the differences between them, unless that could
all somehow be hidden by a Java interface.

> 
> 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.

The Synchronized projects mechanism would work well for that scenario,
provided that you didn't care about being able to check for compilation
errors (since you'd have no local build capability).  In that sense,
when offline, Eclipse becomes just a fancy code editor, right?

>  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.

You mean convert an existing local project to a remote one
automatically?  I think only the Synchronized projects mechanism fills
that requirement at the moment.

Regards,

- Corey