Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "Linux Tools Project/Remote Tools"
(New page: == Models == There are 2 remote models that Linux Tools intends to support. #Local build, remote execution/profiling/debugging #Remote build/execution/profiling/debug The first model is...) |
(→Models) |
||
| Line 6: | Line 6: | ||
#Remote build/execution/profiling/debug | #Remote build/execution/profiling/debug | ||
| − | The first model is one whereby the project builds locally but special | + | The first model is one whereby the project builds locally but special remote launchers are added that allow the user to perform profiling on a compatible remote target. Compatibility includes the platform, required libraries, and installation requirements. As one can guess, this can be difficult when the host and target machines are maintained separately and some systems are completely incompatible (e.g. ppc vs x86). The remote profiling launcher allows the user to specify a remote location to upload the executable to for the purposes of performing profiling. All results of the profiling are shown in the local Eclipse session. At the moment, only Valgrind has support for this remote launching. |
| − | The second model does away with the compatibility requirement by keeping the source code on the remote target and building/executing | + | The second model does away with the compatibility requirement by keeping the project source code on the remote target and building/executing remotely. The host Eclipse session can view the project files and results. To the end-user, the project appears for all purposes the same as a local project. The location of the project is set when the project is initially created. For a C/C++ project, the project wizards have a check-box for specifying a location other than in the current workspace. Once checked, the user has a choice of file systems to use to specify the location. When RSE (Remote System Explorer) is installed, the user has a choice of local or rse. Using RSE, a remote location can be specified, assuming that an RSE connection has been registered for this remote target. Registering a remote location via RSE does not mean that a connection has been established yet. With the remote project model, tools are expected to be location-agnostic and handle the remote location internally. This means that there should be no UI changes required and a user that is familiar with how a local project works can easily use a remote project. |
| + | |||
| + | == Remote Profiling Framework == | ||
| + | |||
| + | The remote profiling framework is found in the linuxtools/profiling component. The main feature is org.eclipse.linuxtools.profiling.remote-feature. The feature is currently not built as part of the Linux tools Hudson builds so one must check-out the source from git [[Linux_Tools_Project/Git]] | ||
Revision as of 15:38, 8 December 2011
Models
There are 2 remote models that Linux Tools intends to support.
- Local build, remote execution/profiling/debugging
- Remote build/execution/profiling/debug
The first model is one whereby the project builds locally but special remote launchers are added that allow the user to perform profiling on a compatible remote target. Compatibility includes the platform, required libraries, and installation requirements. As one can guess, this can be difficult when the host and target machines are maintained separately and some systems are completely incompatible (e.g. ppc vs x86). The remote profiling launcher allows the user to specify a remote location to upload the executable to for the purposes of performing profiling. All results of the profiling are shown in the local Eclipse session. At the moment, only Valgrind has support for this remote launching.
The second model does away with the compatibility requirement by keeping the project source code on the remote target and building/executing remotely. The host Eclipse session can view the project files and results. To the end-user, the project appears for all purposes the same as a local project. The location of the project is set when the project is initially created. For a C/C++ project, the project wizards have a check-box for specifying a location other than in the current workspace. Once checked, the user has a choice of file systems to use to specify the location. When RSE (Remote System Explorer) is installed, the user has a choice of local or rse. Using RSE, a remote location can be specified, assuming that an RSE connection has been registered for this remote target. Registering a remote location via RSE does not mean that a connection has been established yet. With the remote project model, tools are expected to be location-agnostic and handle the remote location internally. This means that there should be no UI changes required and a user that is familiar with how a local project works can easily use a remote project.
Remote Profiling Framework
The remote profiling framework is found in the linuxtools/profiling component. The main feature is org.eclipse.linuxtools.profiling.remote-feature. The feature is currently not built as part of the Linux tools Hudson builds so one must check-out the source from git Linux_Tools_Project/Git