Skip to main content

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.

Jump to: navigation, search

CDT/summitecon2013

< CDT
Revision as of 13:37, 1 April 2013 by Marc.khouzam.gmail.com (Talk | contribs) (Minutes)

CDT Summit at EclipseCon 2013

A one-day CDT summit was held at EclipseCon 2013 in Boston, MA, on Thursday the 28th of March, 2013.

EclipseCon information is here: http://www.eclipsecon.org/2013/

Open to all, even if you didn't sign up :).

Time: 10:00 a.m. to 3:30 p.m.
Room: Beacon Hill 2 & 3

Planned Attendees and Interests

  1. Marc Khouzam - Ericsson
    • Debug, Multicore, Visualizer
  2. Martin Oberhuber - WindRiver
    • Quality, Debug (TCF), Usability, Remote Edit-compile-debug
  3. Sergey Prigogin - Google
    • Refactoring, C++11 features, Codan
  4. Glen Anderson - Analog Devices
    • Debug, Usability, Multicore
  5. Dominique Toupin - Ericsson
  6. Josh Kruck
    • Debug (DSF, MS), Refactoring
  7. Bill Swanson - Tilera
    • Visualization, Multicore, Eclipse/CDT Redistribution
  8. Doug Schaefer - QNX
    • Everything, but currently working on improving Qt support
    • Also if we don't get many more people, we can meeting in one of the evenings as well
  9. Jeff Johnston - RedHat
  10. Jim Adams - Analog Devices
  11. Reibert Arbring - Ericsson
  12. Norman Yee - Analog Devices
  13. Leo Treggiari - Intel
  14. Vladimir Prus - Mentor Graphics
  15. Eric Cloninger - Klocwork
    • Static analysis, refactoring, Android
  16. Mike Wrighton - Mentor Graphics
  17. Greg Watson - IBM
  18. Brian Watt - IBM
  19. Teodor Madan - Freescale
  20. Jesper Eskilson - IAR Systems
    • MBS, TCF, indexer
  21. Patrick Tasse - Ericsson

Proposed Agenda

  • Eclipse 4.x discussion:
    • reactions to 4.x platform
    • CDT compatibility and/or upgrade plans
    • effect on other projects, Visualizer, etc.
      (e.g. if CDT retains 3.x compatibility, related plugins may need to as well)
  • Java 7
  • Advertising new CDT features
    • Dialog popup with "Did you know?" and "Don't show this message again"
    • Other?
  • UI Junit tests: Dependency injection vs other CDT UI test techniques
  • Debug
    • Quick Launches (Local C/C++ App, Remote C/C++ App)
    • Multiprocess launch
  • Remote/synchronized projects
  • ...

Minutes

  • Introductions
    • 25 attendees from 14 companies
    • 7 CDT Committers present as well as 3 Linux Tools committers
  • E4
    • What is the gain to start using E4 APIs?
      • Easier to modify the look of the UI -- No need to move CDT to E4 for that
      • Uniformity of the look and feel -- No need to move CDT to E4 for that
      • QNX feels the UI must be improved -- Does that require E4?
      • Once the CDT community agrees we can use E4 APIs, the decision to do so can be left to individual committers. There does not seem to be a reason we'd have to move all of CDT. We can instead take a joint E4 and 3.x approach.
    • Is there a reason to avoid all use of E4 APIs?
      • We want to keep CDT compiling on 3.x
      • We can re-discuss this requirement for the Luna release
  • Can CDT support platform -1? Meaning the new CDT with the older platform.
    • CDT 8.2 is the first CDT that will allow that. It was not a conscious decision. We don't expect we we will be able, or want to enforce this.
  • Java 7
    • We'll consider moving to Java 7 when the need arises
  • Web integration in Eclipse
    • It is a mess and needs platform involvement. They are well aware of the problems.
  • Advertising new CDT features
    • Welcome page
      • Probably already does all it can. But we have to make sure it points to a the latest wiki N&N or a migration of it.
    • N&N is very important
    • We need to keep the CDT website up to date and describing feature
    • We need auto-discovery of features. For example, people may have upgraded to CDT automatically and therefore will not know to look at the N&N
      • Mylyn has some active pop-up feature for just that purpose. CDT should look into it and copy it.
      • We will need to define policies
    • Can we leverage the splash screen to show the user some feature description when they are just staring at the screen.
      • This is a great idea!
      • Different images can be randomly shown
      • This must be package based (EPP)
      • As for vendors, it will be up to them to re-use this ability or not
    • Dialog popup with "Did you know?" and "Don't show this message again"
      • Not a user-friendly solution
  • Redistribution of CDT
    • Maven/Tycho is the way to go
  • CDT Launches
    • too many launch types, should be able to do more single-click launch of apps
      • local start
      • remote start
      • attach local
      • attach remote
    • Ideas proposed
      • quick-launch in run/debug menus
      • add non-project start debug menu item to Debug As... submenu
      • use "clickable" attach/start... nodes under the gdb process node
      • hyperlinks on the "gdb" node ("Start process / Attach process")
      • maybe have tooltip on gdb node, or "Click me" text
      • add "Right click to do X", to suggest looking at context menu
      • quick launch that just starts gdb and when "Select Binary" is selected, the value is populated in the launch, which gets added to quick-launch menu
      • adding one or two predefined launches to CDT
      • add "pencil" edit button to launch line
      • postpone selection of local vs. remote, default is local
      • one launch, wizard to select "essential" high-level options
    • perhaps along with other stuff we just need to clarify the names of the launches:
      • C/C++ Run Local App
      • C/C++ Run Remote App
      • C/C++ Attach Local App
      • C/C++ Attach Remote App
      • Maybe internally these all create a single launch type, but it's good to have the various names for new-user discoverability.


Decisions

  • E4
    • CDT 8.2 (Kepler) will not use any E4 APIs to keep compatibility with 3.x.
    • CDT will not commit to supporting 3.x as a platform for the CDT 8.2 release.
    • For the future CDT release (Luna), the decision with regards to using E4 APIs is not taken yet. It will be discussed further after the Kepler release.
  • Java
    • CDT 8.2 (Kepler) will run on Java 6
    • No decision to move to Java 7 for the next release at this time.

Back to the top