[cdt-debug-dev] My annual rant about why refactoring and C/C++ indexing

[oyvind.harboe@xxxxxxxxx]

In my experience CDT fails miserably to be adopted as an IDE when compared to
Eclipse JDT.

I've seen that CDT is quite successful in getting adopdated as GDB GUI.

First some observations(from embedded developers point of view) and then some
speculation about what's going on:

- Focus is a lot of the time on hardware issues: voltage supplies,
  phase lock loops, high-frequency signalling issues, power consumption,
  part cost, etc. Some time is left over for software issues: choice of
  embedded operating system(if any), writing or selecting drivers for hardware
  parts, etc. The application itself is oftentimes not very big. How
  much can you fit into 10-100k's of RAM anyway? :-) Java is probably
  nowhere on their radar before encountering Eclipse CDT.
- Users get angry and frustrated about Eclipse CDT "freezing up"
  and being "really slow". Some manage to make the connection that they
  are being hosed by CDT C/C++ indexing that is slowing down the machine.
  The first reaction is "how do I turn it off?". When using CDT as a debugger
  there is no need to enable C/C++ indexing. Also regressing to
  Insight is common. Insight *really* sucks, so this forces them kicking
  and screaming to reconsider CDT as a GDB GUI.
- Refactoring is a MASSIVE undertaking in C/C++. Even more so than in Java.
  It's the only human artifact visible with the naked eye from space :-)
  Java developers who also do C++ are all hot and bothered about this, but
  embedded developers who *barely* do C++(they are used to CPU's which use
  10-100kBytes of RAM), refactoring is just lightyears away from what
  interests them.
- Programs are built using existing build systems. Eclipse CDT will not
  influence the decisions on how programs are built. CDT managed build is
  not on the radar in any form or shape. Developers *might* be interested
  if CDT has some simple way of allowing existing build systems to be
  invoked from CDT. E.g. running make, eCos build programs, automake(Linux),
  etc.
- Eclipse itself is very intimidating. This ranges from navigating the
  Eclipse web-pages to understanding which plugins that need to be installed,
  installing Java in the first place, understanding perspectives, possibly
  first exposure version control/CVS, etc.

Some open questions:

- Is it a goal of CDT to get embedded developers to adopt CDT?

- Does  CDT care whether or not C/C++ indexing is used as long
  as CDT otherwise gets adopted?

- Does CDT care whether or not CDT is involved in the build
  process as long as CDT is otherwise used?

- Does CDT care whether or not CDT is being used for editing,
  refactoring, etc. as long as CDT is otherwise used?

Some (my) conclusions:

Assuming it is a goal to get as many embedded developers on board
as possible, I think the following would be effective:


- Package CDT as Insight killer. This will be the minimum threshold,
  first encounter to CDT. Ultimately this requires CDT packaged as
  a GDB GUI frontend without C/C++ indexing, CDT project build capabilities,
  etc. with a standard Windows installer. Probably it would be a good
  idea to include the Java JRE in the Windows installer package.
  Package Eclipse CDT as an RCP app. This problem is being attacked
  from several fronts(at least a dozen PR's are open and several of
  them are being actively worked on).
- Stop trying to convince developers to use CDT to build their
  applications. This is a dead end. Instead treat developers existing
  build procedures as first class citizens. Abandon the CDT project
  concept and add a capability to invoke existing build scripts and
  capture output(to pick up errors) + capability to terminate build.
  CDT can most humbly be told basically three things: