[
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 whyrefacto ringand C/C++ indexing sucks
|
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Daryl Spitzer
> Sent: Monday, March 27, 2006 2:01 PM
> To: CDT General developers list.
> Subject: RE: [cdt-dev] Re: [cdt-debug-dev] My annual rant about
> whyrefactoringand C/C++ indexing sucks
>
> > Insight killer. The first step has been taken: Nokia contributed
> > code for projectless debugging.
>
> I heard they contributed code to create a project from an executable.
> Where can I get more information on this?
>
Some patches can be found here;
https://bugs.eclipse.org/bugs/show_bug.cgi?id=39640
> > There is also an idea to implement the RCP client that includes
> > the debugger-related plugins only.
>
> Doesn't the CDT debugger code make a lot of references to IProject? I
> wonder if it would be easier to create such an RCP client based on the
> platform debugging APIs, rather than CDI?
The platform has lots of IResource type references too... Realistically the
RCP type debugger would still need a workspace, maybe it could look like
more a private workspace just for the RCP debugger hidden from the user.
>
> --
> Daryl
>
>
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Mikhail Khodjaiants
> Sent: Friday, March 24, 2006 12:05
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Re: [cdt-debug-dev] My annual rant about
> whyrefactoringand C/C++ indexing sucks
>
> My two cents...
>
> First, there are non gdb-based debugger implementations for CDT. Nokia
> released their Eclipse-based tool a month ago that includes a non-gdb CDI
> debugger. Other companies are working on their versions.
>
> Insight killer. The first step has been taken: Nokia contributed code for
> projectless debugging. There is also an idea to implement the RCP client
> that includes the debugger-related plugins only.
>
> Managed make: according to the number of postings in the CDT news group
> and
> this mailing list, the interest expressed in it by users is large.
>
> Mikhail Khodjaiants
> ----- Original Message -----
> From: "Daryl Spitzer" <DSPITZER@xxxxxxxxxx>
> To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
> Sent: Thursday, March 23, 2006 6:54 PM
> Subject: 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
> >
> >
> > _______________________________________________
> > 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
