Bugzilla – Full Text Bug Listing
| Summary: | Not possible to specify remote SDM binary default path | ||
|---|---|---|---|
| Product: | [Tools] PTP | Reporter: | Rodrigo Fraxino Araujo <rfaraujo> |
| Component: | Debug UI | Assignee: | Greg Watson <g.watson> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | cjashfor, g.watson, rfaraujo, wainersm |
| Version: | 5.0.6 | ||
| Target Milestone: | 6.0 | ||
| Hardware: | PC | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Bug Depends on: | 360139 | ||
| Bug Blocks: | |||
| Attachments: | |||
|
Description
Rodrigo Fraxino Araujo
This bug and 360139 are really the same issue. For the SDM binary, there is some code that attempts to locate it, but this is difficult when the target system is remote since there is no way to know where the binary is installed. It would be possible to supply this path using an extension point, but that would only be correct for a very limited range of systems. The backend debugger and debugger path (effectively the path of gdb), which is the subject of 360139, has a similar issue. It's not really possible to specify these using a preference either, since preferences apply globally, but each launch configuration could conceivably require a different SDM and backend path. With the new XML-based RM framework, I'm thinking a different approach is warranted. Something like this: 1. An RM configuration file will contain a pre-defined path for the SDM and specify the backend and backend path. Generic configuration files could leave the SDM path empty, while site-specific configuration files could specify the known location of SDM. Since configuration files can be added a will (just by copying them into the workspace), this would allow the default location to be customized if necessary. 2. When an RM is created, there will be an additional wizard page that allows these paths to be overridden, so there will be a separate version of these paths for each instance of an RM in the Resource Managers view. 3. When an RM is selected on the Resources tab of a launch configuration, the per-RM instance of these paths will be copied to the Debugger tab. This allows the user to further edit the path if desired. Note that this will not work for legacy RMs. However, since these are being phased out anyway, it shouldn't be a big issue. The current Debugger launch preference on the SDM preference page will be removed, since they would no longer be required. Let me know if this sounds acceptable. Thanks! From what I understood it definitely sounds acceptable. What I quite didnt follow was where and how this XML file would be accessed by PTP. The XML file with default values would stay outside the PTP package and its location could be defined in an extension point? The XML files are currently used for the PBS resource manager definitions, but we will be transitioning all resource managers to use them in the future. They can either be located in a plugin, in which case they are fixed for a particular Eclipse installation, or the user can put these files in a special directory in their workspace. The RM framework will pick up the definitions from both locations automatically, but there is no way to override an existing configuration other than editing the XML and placing the modified version in the workspace. I don't expect users to be modifying these configuration files very often, since they are quite complex. Normally they will be provided via a plugin, but site specific configurations may be supplied by sys admins that can be downloaded and placed in the user's workspace. If a user needs to modify the SDM or backend paths, then they can do this when the create a resource manager instance (which gets its default information from the configuration file), or when they create a debug launch configuration. Hi Greg, Thanks for explaining. That would work for what we need. In which release do you think it will be available? Best regards, Rodrigo. I just want to point out here that this bugzilla is reporting two problems: 1) Even if you enter the path to the SDM, and click "Apply", that setting is not preserved; if you re-open the debug launch dialog, the debugger path field is empty again. 2) That the SDM path cannot be supplied via an extension point. I see that the discussion centered around problem 2, but problem 1 needs to be solved as well. Problem 1 is specific to Linux and should be fixed in 5.0.5 (SR2). Created attachment 215730 [details]
Patch to make possible to specify a default path for SDM in debbugers configuration via an extension point
Patch to make possible to specify a default path for SDM in debbugers configuration via an extension point
Hi, it looks like this patch no longer applies cleanly. Would you be able to submit an updated patch? Thanks! Created attachment 216319 [details]
Support for SDM default path
Removed conflicts from patch. Please apply this prior to the gdb one. Thanks!
It still doesn't seem to apply to master. Have you pulled from git recently? Created attachment 216344 [details]
Added support to specify SDM default path via extension point.
Hi Greg.
I applied it successfully here.
There was a warning about trailing whitespace, which I removed now.
Could you confirm it?
Thanks!
No, the whitespace was not the problem. I suspect it has something to do with how you are creating the patch. Are you using Eclipse to create the patch? In any case, I've applied a modified version of this patch to master (including some changes to the extension point). Please verify that it works for you. Closing as fixed. |