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

[Ramana Radhakrishnan <ramana.radhakrishnan@xxxxxxxxxx>]

Hi ,

I am writing this from a perspective of having used Eclipse at times and
supporting a number of users within my organization for use of gdb and
debug tools. I am an interested onlooker to the developments that happen
in CDT land . 

Again my perspective originates from feedback and conversations with
developers who work at different layers of the linux software stack
right from the kernel to the apps. 

> 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. :-)

The workflow and the jargon are sometimes so different for the embedded
developers that people prefer using emacs and gdb for their debug
environments with embedded board. Integrating build environments like
the Makefiles for kernel drivers in here is really quite painful. 


> > 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.

Or through emacs for that matter. At some points of time its only source
level debug that they seem to want . 

> 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.

Downloading to flash, or possibly creating ROM filesystems for kernel
guys could be a requirement . 
<some portion snipped.> 

> 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:

Unless there can be a method for people to use their build systems very
easily inside the CDT and be able to understand the mapping between
where the executable finally lands up .  The CDT ends up generating
output in folders which users at the end of the day go around searching
in. 

The other problem with a large number of linux packages is the autoconf
based build mechanisms and integrating that in. Its a bit of a hack to
get that going too. But this was the last time I tried to debug gcc
within eclipse (thats not something that your typical embedded developer
would do :) and its enough for me to use emacs to do whatever debug I
want to do), there are enough autoconf based linux apps that need an
easy way for the user to configure and build within the same setup.
(s)He does not want to have to do some stuff on the command line and
then get back to working within eclipse.

Getting support for all the build mechanisms right from the basic
embedded user (as Steve mentioned in an earlier email) to autoconf based
build mechanisms (e.g. gcc) or the BSD based Makefile mechanism (like
LLVM) or the make menuconfig based build system for the Linux Kernel or
other apps in the kernel land is quite a bit of pain. I am not sure
about how quickly this can all be considered in the CDT . 


Again my knowledge might be slightly dated , so if there are any
inaccuracies please forgive  . This is just my 10 paise on the topic . 

cheers
Ramana

-- 
Ramana Radhakrishnan
GNU Tools
codito ergo sum (http://www.codito.com)