Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-debug-dev] My annual rant about why refactoring and C/C++ indexing sucks 
Hi,
I'm writing from the perspective of someone who wants a really great IDE to use with the GNU tools I am targeting for MCUs. 

Mikhail Khodjaiants wrote:

Oyvind,
I am packaging both messages together and forwarding it to the CDT developers list: 


In my experience CDT fails miserably to be adopted as an IDE when
compared to Eclipse JDT.
I don't know how well JDT does, but there is a lot of customer resistance to CDT, because its not what they are familiar with. Every other IDE looks pretty much the same. Eclipse is the odd man out. I think, maybe, this is not a big problem long term. If Eclipse can keep up its momentum, Eclipse will become the norm, and all the other IDEs will look odd. :-) 
I've seen that CDT is quite successful in getting adopdated as GDB GUI.
True. However most embedded developers really really want an IDE, though most of the time I would rather use the GNU tools from the command line. Getting most embedded developers to adopt a tool-chain *demands* an GUI system they feel comfortable with for the whole tool chain - not just the debugger. Most developers working with small MCUs are *totally* hooked on IDEs.
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.
10k is big for most embedded development. Most small MCUs have just 1 or 2 K of RAM, and a few K of flash or ROM. These days, the code for a lot of these devices is being developed in C.
The hardware issues affect the ideal IDE somewhat. Although the embedded processors have many non-standard features the IDE needs to support, some are common - such as erasing flash - and ought to be supported in a standardised way by the IDE, for consistency across devices. 
- 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.
With a lot of current embedded platforms based on Eclipse people get angry and frustrated for a variety of reasons. Most implementations still seem pretty immature. 
- 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.
I find people refactor quite a lot in small embedded applications. When the program is small, refactoring it isn't such a huge task, so people are more prepared to undertake it. However, because of the program size, refactoring probably doesn't need any IDE support.
Certainly C is a must these days. C++ support is increasingly being provided by tools for small embedded devices, but it rarely seems to be used. 
- 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.
Most people can't even figure out what managed builds are all about. They just want to identify a list of source code files, set a few options, and say "go". Remember, a large percentage of small embedded applications consist of only one source code file. 
- 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.
It certainly is intimidating. I am still unclear how much of that is inherent in its design, and how much is because it is different from what people are familiar with. 
Some open questions:

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

The embedded people certainly want it to be.

- 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).
Agreed. A replacement for Insight is the most critical requirement for embedded use. 
- 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:
I'm not sure about that. I think most embedded user's current build processes are the arrangements in the IDE they use today. You certainly cannot port most of those to Eclipse. Most embedded people, at least those working with smaller devices, are not comfortable with make files, or other forms of scripting. Most have never used them. 
1. Where to find the source for the purpose of editing it and looking
  up relative paths

2. How to invoke the build procedure(oftentimes as simple as executing
  "make" with pwd in a particular place)

3. Where to find the output(oftentimes the .elf files).
Øyvind
I think everyone using the GNU tools for embedded processors desperately wants Eclipse to be a great IDE for their tools. Right now it tends to be no better than the least worst option, and that's really sad. 

Regards,
Steve

Back to the top