[
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
|
----- Original Message -----
From: "Daryl Spitzer" <DSPITZER@xxxxxxxxxx>
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Sent: Monday, March 27, 2006 2:00 PM
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?
Yes, that's correct. They added a wizard to import an executable to the
workspace. For more information see
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?
Are you proposing to rewrite all CDI-based implementations? I believe it's
mich easier to get rid of the references.
--
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
