Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "CDT/Obsolete/APIBreakages"
Line 12: | Line 12: | ||
* Remove support for old Apple GDB. '''Alvaro will have a look''' | * Remove support for old Apple GDB. '''Alvaro will have a look''' | ||
* Delete CDI plugins '''Doug will nuke it''' | * Delete CDI plugins '''Doug will nuke it''' | ||
+ | ** Clean up CApplicationLaunchShortcut to no longer chooseDebugConfig() which is a CDI concept '''Marc will look at that''' | ||
* Cleanup old-style projects '''Marc-Andre will head this''' | * Cleanup old-style projects '''Marc-Andre will head this''' | ||
** Our tests still use old-style and migrating them is not trivial | ** Our tests still use old-style and migrating them is not trivial |
Revision as of 10:14, 15 October 2015
CDT 9.0
This page is attempt to collect possible API breaking proposals for next CDT release
Proposed API-breaking changes
- Remove all methods, interfaces and classes that have been deprecated since around 2 years CDT 8.?.0 and are not currently used in CDT code.
- Marc K to do the DSF/DSF-GDB part
- Improves readability
- Reduces maintenance
- Could be contributions from a hackathon
- Suggested rules (not mandatory): something deprecated for around 2 years and not used by CDT itself
- Remove support for old Apple GDB. Alvaro will have a look
- Delete CDI plugins Doug will nuke it
- Clean up CApplicationLaunchShortcut to no longer chooseDebugConfig() which is a CDI concept Marc will look at that
- Cleanup old-style projects Marc-Andre will head this
- Our tests still use old-style and migrating them is not trivial
- Remove code that migrates from .cdtproject (pre CDT 4.0)
- Removing UI that is not used
- Old scanner discovery (Language setting provider)
- At least we should not show both in the UI to a user
- What about LR parser?
- Need to follow-up with IBM
- UPC, XLC plugins may need them, which are used by PTP
- Can we move it to PTP?
- p2 plugin Doug will decide what to do here
- Could it be part of p2 itself?
- o.e.cdt.core.native (Spawner) Doug
- Used by o.e.remote but CDT uses o.e.remote => circular
- Spawner should be moved lower than CDT. Where? Maybe in CDT but be independent. That still solves 'circular' dependency.
- native should have its own pom/build
- Remove IA64, QNX as they are not available from platform Doug
- Remove o.e.linuxtools.cdt.autotools.core Jeff
- Merge cross-GCC with regular-GCC
- Cleanup/Rename CDI* classes used by DSF Marc K
- C/C++ Problem Markers - add API to deal with column information Alena
- Rewrite error parsers to use a better regex library (java.regex.Pattern is part of API now) because build is horribly slow from IDE strictly because of error parsers. Doug, as part of the new build effort
- Need to fix API
- Be careful with performance
- Rewrite ui for debug tabs, all current ui controls are APIs...
- Check with list if anyone is against such changes
- Java 8 changes Ok for CDT plugins to use Java 8. Migration of each plugin when/if needed
- Make (some) dsf.ui and dsf.gdb.ui classes as API.
- Pay attention to good extensibility for some of these classes. Probably best to makes changes to address specific use-cases
- We will only do this upon request and if there is a good reason
- Separate the Run launch delegate into its own delegate. The Run delegate should use LocalRunLaunchDelegate.java instead of LocalCDILaunchDelegate.java Marc
- In the debugger, make thread a string instead of an integer. GDB may move to use strings. See IMIExecutionDMContext Marc
- MIBreakpoint MI uses an int as an id. It should be a string. Marc
- Changes for Grouping feature and its use of IContainer... Containers may no longer be directly mapped to processes. Marc
- Replace IRunControl.isStepping() and IRunConrol.isSuspended() with asynchronous versions???
- Revisit the CDT Breakpoint action framework Mikhail
Proposed process
- Mark classes that will disappear as Deprecated. Can we do it on the Package? Maybe using javadoc. Do this ASAP to warn people.
- Select an API-breaking change to work on
- Estimate the impact (code changes) of the change on the APIs
- Communicate that impact to the cdt-dev list to notify possible impacted parties