I'd love to do it but unfortunately
there are only 24 hours in a day :)
On 2013-07-06 10:43 AM, Doug Schaefer wrote:
I'd love to see lldb support. Hearing good things about it. I
don't know the M2M interface to it but assuming the protocol is
clean, it shouldn't be hard to integrate. Other than a lot of
work that is.
Doug.
From: xgsa
Sent: Saturday, July 6, 2013 4:52 AM
To: CDT General developers list.
Reply To: CDT General developers list.
Subject: Re: [cdt-dev] Re : Re: Adding a
profile tool to a standard CDT toolchain
As a regular CDT & VS user I
can say that advantages of writing code in CDT definitely
outweigh the
limitations of debugging with it,
so I prefer to use and really love CDT. Thank you guys for
working on it!
From my experience the main usability problems comes not from
CDT debugging support (DSF at least), but from gdb that is
used behind the scene. We have a quite big C++ project with
a few dozen of shared libraries and gdb performance is not as good
as of VS debugger. In addition unfortunately gdb itself often
crashes during the debugging session, so sometimes I have to
debug not only my application, but also gdb itself. In this
connection, I am wondering whether there are plans about lldb
support. Or at least are there any difficulties expected to
implement it (except a lot of work, sure)?
There are also a few things to improve in CDT debugging
support. That most issues are related to Variables &
Expressions views and possibly
affect the Eclipse Platform rather than CDT
itself, however as an ending user I compare the complete
usability of IDE. Here are a few items:
Something similar to VS visualizers feature [1]. VS has
a nice feature that allows to visualize the value of a
variable of some type with a custom GUI (there are a few
built-in visualizers, but they could be easily extended
with user plugins). It is like gdb pretty printers, but
work on GUI level. For example separate dialog for
examination of variables with long multiline strings or
XML/HTML content viewers (BTW currently viewing long
strings is almost impossible). Taking into account that
gdb has a python support, this feature could be really
flexible.
GDB errors handling in Expressions view. When I add an
invalid _expression_ (e.g. variable) to the view I am
getting "Error: Multiple errors reported.", but as I can
see in gdb traces console, gdb itself returns "No symbol
\"b\" in current context." and "-var-create: unable to
create variable object". The refresh button directly in
the value column of the view would be also helpful, but
probably it is a Platform (not CDT) issue.
Hover for the variable values in Variables &
Expressions views on Linux. Often the
value of the variable or _expression_ does not fit into
the value column. In such cases on Windows the hover
is shown. Probably it is a common issue of SWT or even
GTK (that is used by SWT on Linux), but I really miss
it especially here.
Hot key for "Move to line (C/C++)" action. Not very
important, but a useful improvement.
Yes, as Java programmers, we
don't get to use the CDT debugger very much. Even less
get exposed to the other debuggers such VS.
It would be great to get user
feedback on what is missing in the CDT debugger.
Marc-Andre had mentioned that
we are missing the ability to show the return value of a
method automatically. That would be
a great feature to have.
Are there other things that
an experienced VS user misses from CDT debug?
Thanks
Marc
From:
cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Marc-André Laperle Sent: Wednesday, July 03, 2013 1:36 PM To: CDT General developers list. Subject: Re: [cdt-dev] Re : Re: Adding a profile
tool to a standard CDT toolchain
Hi Guy,
That's good to hear! I find this comment intriguing: "(At
least for writing code not debugging)". Are you saying
that because you feel some features are missing when
debugging? I'm sure the debug guys would appreciate
feedback from someone coming from Visual Studio (perhaps
in a new thread).
Yet I have to say that I really love Eclipse and
all its capabilities and architecture...
For 25 years I have worked only with Visual Studio
IDE. From 4.0 up to 2012 and C++. I couldn't believe
there was a better IDE than Visual Studio or C++
language. Until I switched job and had to work with
Eclipse and Java..! After 20 years with almost the
same IDE I struggled a lot and couldn't find the IDE
tools I wanted! It took me a year...Helped by 25 years
younger developers than me to patiently bring me to a
point were I was wowed by all the capabilities of
Eclipse! I Learned a lot both at the coding and
architecture level. And once I mastered Eclipse IDE I
wouldn't want to go back with VS (At least for writing
code not debugging)! I became a more proficient coder
with Eclipse and really enjoyed the coding experience
with it.
Since Microsoft released Visual 2012 I really hated
what they did with the IDE. Thousand of developers are
crying to Microsoft telling tell how they hate what
they did to their beloved IDE.
So I hope that Eclipse CDT IDE will grow in
architecture and coding stability. Its a great IDE.
Thought that I believe much work is left to do for
that they seems to be very close to bring the CDT to
maturity.
After
much digging in the CDT code I
have progressed and I am now able
to have the profiler tool kick-in
with the appropriate inputs type
and output target. However I am
left with a feeling of something
unfinished regarding how the
output types (Primary or
secondary) can be defined and are
processed up to the command step
building. For example I don't see
how you can really produce many
outputs (primary and secondaries)
from a single tool since the
command line pattern have only one
${OUTPUT} dedicated to the primary
output.
I have
nonetheless be able to bypass this
problem by custom command line
generation and using option
definition. However I feel it
shouldn't be that hard.
To
have my profiler step builder
created and executed I have had to
solve an issue for which I have
created a bug:
https://bugs.eclipse.org/bugs/show_bug.cgi?id=412146 The
calculateOutput method of build
description wrongly uses the tool
outputs file extension attribute
to create the resource outputs of
any outputType associated to the
tool. This prevent the build
manager to resolve the appropriate
build steps.