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. I noticed that in the RDT branch of linuxtools, you have locked the profiling launcher into using the project's URL for acquiring the remote machine. I also realize this is something we discussed earlier, and had settled on this solution. However, thinking more long term, I'm no longer convinced that this solution is flexible enough. I'm going through the OProfile plug-in and have found most of the places where local machine access is assumed, and I'm thinking that we'll want to have a remote tab which will allow the user to change the remote machine, and the act of changing the machine used will cause some of the other tabs to be re-calculated and populated. For example, the oprofile events tab will need to be re-loaded because the machine to be used for execution may not have the same processor chip as the machine used for building. So I will need to add some change listeners to some of the tabs. Any thoughts? - Corey _______________________________________________ linuxtools-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/linuxtools-dev
