Community
Participate
Working Groups
Build Identifier: At present, GDBBackend.getGDBPath is private, so a custom class derived from GDBBackend cannot easily override just the logic for determining the gdb name. Also, there's fLaunchConfiguration field, but it's not exposed to derived classes. I would recommend adding an accessor method. I can provide patches for both if so desired -- but it seems that sending patches for such trivial changes is not gonna help anybody ;-) Reproducible: Always
Created attachment 173194 [details] Fix (In reply to comment #0) > At present, GDBBackend.getGDBPath is private, so a custom class derived from > GDBBackend cannot easily override just the logic for determining the gdb name. I made it protected in the attached patch. Committed to HEAD. > Also, there's fLaunchConfiguration field, but it's not exposed to derived > classes. I've made fLaunchConfiguration final in this patch. Since it is set to a value that is be passed to the constructor, then an overriding class must also have that parameter and can create it's own fLaunchConfiguration. Is that ok for you?
Ling, can you review this two-line change?
If the solution is not sufficient for some reason, please re-open.
Thanks for looking into this. I am not sure about fLaunchConfiguration. Yes, derived class must accept a config in its constructor. However, forcing it to have another member to hold a configuration, and assign to that member, seems unnecessary, given that FinalLaunchDelegate already has this information and will always have it.
(In reply to comment #4) > Thanks for looking into this. > > I am not sure about fLaunchConfiguration. Yes, derived class must accept a > config in its constructor. However, forcing it to have another member to hold a > configuration, and assign to that member, seems unnecessary, given that > FinalLaunchDelegate already has this information and will always have it. It may seem overly careful, but I prefer not to add APIs unless really necessary. Having a local member does not seem like such a big deal.
*** cdt cvs genie on behalf of mkhouzam *** Bug 318304: Allow for better overriding of the class. [*] GDBBackend.java 1.18 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/gdb/service/GDBBackend.java?root=Tools_Project&r1=1.17&r2=1.18
(In reply to comment #2) > Ling, can you review this two-line change? Looks good to me.
Could you imagine a situation where GDBBackend does not need to store launch configuration, and access it from various methods? It seems that it's only possible if GDBBackend is completely redesigned, in which case an extra method is the least of the problems. Anyway, I've hacked my code around this. Thanks for the other fixes!
