|Re: [linuxtools-dev] rethinking acquiring the remote machine's connection for remote launches|
On 11/15/2011 08:55 AM, Jeff Johnston wrote:
On 11/14/2011 05:56 PM, Corey Ashford wrote:Hi Jeff, One of the use cases we'd like to support is one where a developer is doing cross compilation on his laptop, and then later, executes on a remote machine. Under this model of cross compilation, it doesn't make sense to acquire the remote machine's name simply by looking at the project's URL. So, ideally, perhaps it would be best to default the launch config to use the project's location (particularly for the case of remote builds), but allow it to be set to a different machine by the developer.There are two models. One is you are executing where the project is and the project is remote. In that model, the location of the project is simply specified as a remote location. Paths should ideally be shown as paths on the location system so UI doesn't require changes. That is what the RDT branch is implementing. The other model is the current remote model whereby you are executing a locally built executable on a compatible remote system. This is the Valgrind remote launcher model whereby the user specifies where the executable is to be run. What you are specifying above falls under the 2nd model that exists today. So, you can use the profiling tab page that I added for Valgrind which currently allows you to specify an RSE connection and to customize that page with whatever UI widgets you want (e.g. location of valgrind). You can then use the RemoteConnection class to shuttle files or to execute commands on the remote system.
I was hoping that we could use one launcher for all three models of development (local, cross, remote).
Back to the top