RE: [cdt-dev] Re: [cdt-debug-dev] My annual rant about whyrefactoringand

["Daryl Spitzer" <DSPITZER@xxxxxxxxxx>]

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

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

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