[
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 whyrefactoringand C/C++ indexing sucks
|
Hi Daryl,
We'd love the help on the DSDP-DD for a prototype. Probably determining whether you need the flexible hierarchy for the prototype is a good first step. Given that your company builds FPGA's, it makes sense that the flexible hierarchy would be useful. You may also have use of the Target Management framework, too, for things like FPGA programming.
Doug G
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Daryl Spitzer
Sent: Thursday, March 23, 2006 6:54 PM
To: CDT General developers list.
Subject: RE: [cdt-dev] Re: [cdt-debug-dev] My annual rant about whyrefactoringand 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
