[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Re: [cdt-debug-dev] My annual rant about whyrefactoring and C/C++ indexing sucks
|
Another perspective...
- We generate a build system (a BSP and a sample application from a chosen template) for most of our customers (except for those who already have their own) and so (either way) have no need for managed make.
- A significant fraction of our customers (perhaps the majority) just want a replacement for Insight: they want a GUI debugger than they can launch without having to create an Eclipse project and launch configuration. I may be able to contribute resources towards this--but would this be best implemented as a modification to the CDT debugger or as a "prototype" debugger as part of the DSDP DD project?
- Our customers haven't expressed any interest in refactoring (yet).
> - Eclipse is intimidating we have done a lot of work automating
> various parts of Eclipse/CDT for the user...
Ditto.
--
Daryl Spitzer
Manager, Embedded Processor Tools
Altera Corporation - Santa Cruz Technology Center
dspitzer@xxxxxxxxxx
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Adam Finucane
Sent: Thursday, March 23, 2006 14:59
To: CDT General developers list.
Subject: Re: [cdt-dev] Re: [cdt-debug-dev] My annual rant about whyrefactoring and C/C++ indexing sucks
Just to give another perspective on the requirements of embedded developments.
- We find that developers do not have existing build systems and would rather
have the IDE manage the building for them.
- Simple refactoring is handy, change function arguments, renaming files, but
we haven't had much feedback about.
- Being able to easily modify keyword highlighting in the C editor would be
good. Many embedded compilers support keywords that are not ANSI or GNU.
- Eclipse is intimidating we have done a lot of work automating various parts
of Eclipse/CDT for the user, installer (installs Java), creation of a default
debug launch on project creation, custom debug perspective where disassembler
and memory views a are opened by default, etc.
Adam Finucane
HI-TECH Software
On Friday 24 March 2006 02:32, 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'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:
>
> 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
>
> ----- Original Message -----
> From: <oyvind.harboe@xxxxxxxxx>
> To: <cdt-debug-dev@xxxxxxxxxxx>
> Sent: Thursday, March 23, 2006 3:06 AM
> Subject: [cdt-debug-dev] My annual rant about why refactoring and C/C++
> indexing sucks
>
> > 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:
> >
> > _______________________________________________
> > cdt-debug-dev mailing list
> > cdt-debug-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-debug-dev
>
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
