Probably to do a full code analysis, you
will need the CDT DOM which will provide AST level information. Unfortunately
that work is a few months from completion and will be available in an upcoming
release (but not the next one J).
Doug
Schaefer
Rational Software - IBM Software Group
Ottawa (Kanata), Ontario, Canada
-----Original Message-----
From: Walter, Patrick A [mailto:Patrick.A.Walter@xxxxxxxxxxxxxxxxxxxxxxxxxxxxx]
Sent: Tuesday, April
08, 2003 1:22 PM
To: 'cdt-dev@xxxxxxxxxxx'
Subject: [cdt-dev] RE: cdt-dev
digest, Vol 1 #196 - 6 msgs
I've been talking to vendors who have added plugins to
eclipse. This vendors tool, CodePro Studio, provides java code analysis.
We are also wanting to analyze C/C++ code. They stated that if CDT provided a
AST Model that we could interface their tool with eclipse. Does CDT
provide this model? I'm not sure what that is. Do you know of any tools
that integrate with eclipse that performs both java and C/C++ code
analysis? We know of Parsofts Jtest and C++Test. They say it
"integrates" with eclipse.
Thanks in advance for for your help/information.
Patrick Walter
-----Original Message-----
From: cdt-dev-request@xxxxxxxxxxx [mailto:cdt-dev-request@xxxxxxxxxxx]
Sent: Tuesday, April 08, 2003 11:00 AM
To: cdt-dev@xxxxxxxxxxx
Subject: cdt-dev digest, Vol 1 #196
- 6 msgs
Send cdt-dev mailing list submissions to
cdt-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web,
visit
http://dev.eclipse.org/mailman/listinfo/cdt-dev
or, via email, send a message with
subject or body 'help' to
cdt-dev-request@xxxxxxxxxxx
You can reach the person managing the list at
cdt-dev-admin@xxxxxxxxxxx
When replying, please edit your Subject line so it is
more specific
than "Re: Contents of cdt-dev
digest..."
Today's Topics:
1. Re: Fwd: 1.0.1 Parser (Alain Magloire)
2. Re: NT Launch/Build
Abort (Alain Magloire)
3. IParent (Chris
Songer)
4. Re: NT Launch/Build
Abort (Chris Songer)
5. Re: IParent (Alain
Magloire)
6. Conference call
minutes, April 3rd CDT call (Sebastien Marineau)
--__--__--
Message: 1
Subject: Re: [cdt-dev] Fwd: 1.0.1
Parser
To: cdt-dev@xxxxxxxxxxx
Date: Mon, 7 Apr 2003 12:05:15
-0400 (EDT)
From: "Alain Magloire"
<alain@xxxxxxx>
Reply-To: cdt-dev@xxxxxxxxxxx
>
>
> Hi!
>
> Here's the test case that
caused the lockup for us. I believe we were
> current on the parser, but
perhaps am wrong.
>
Agreed.
Patch applied.
Thanks for looking at this.
--__--__--
Message: 2
Subject: Re: [cdt-dev] NT
Launch/Build Abort
To: cdt-dev@xxxxxxxxxxx
Date: Mon, 7 Apr 2003 15:07:45
-0400 (EDT)
From: "Alain Magloire"
<alain@xxxxxxx>
Reply-To: cdt-dev@xxxxxxxxxxx
>
>
> Hi!
>
> No patch this time since I'm
sure the build model in the head is too far
> away from 1.0.1 for the patch
to be useful and many of the changes were in
> Tensilica specific launchers.
Never-the-less I did want to take a moment to
> mention an issue we hit in
usability testing with debugging and building on NT.
>
> The basic problem has to do
with gdb and the NT filesystem. While gdb is
> running it keeps an open file
descriptor to the executable. NT will not let
> you remove or modify a file
that is presently opened. This causes makefiles
> run on NT to be unable to
write an executable. The message that the linker
> outputs does not lead you to
the conclusion "this was because I've got an
> open launch on this exe in a
perspective that's currently not even visible."
>
> We added a scan of the running
launches to the builder and if any launches
> are involved with the project
being built then we give the user a choice
> between terminating the
launches or continuing the build.
>
> Perhaps this issue just
affects our tools, but I suspect it's not unique to
> us. As you look at the build
model on the head, please do keep this
> "exclusive" nature
of the NT file system in mind. You can't build and debug
> at the same time and the user
does get confused about the build failures
> this causes.
>
Some other possibilities:
- It is a little vague in my
memory, but I do remember that you can tell gdb
not to hold a write access
when debugging. Not sure it that will solve the problem.
- Another possibility is to create a Session
property on the project
that the builder could check
before building.
- The debugger could make a copy of the executable
before running.
But all the solutions are messy and you do not want to
push this
on other platform less
brain-d^H^H^H^H^H^H^H .. susceptible to this behaviour.
--__--__--
Message: 3
Date: Mon, 07 Apr 2003 12:21:25
-0700
To: cdt-dev@xxxxxxxxxxx
From: Chris Songer
<songer@xxxxxxxxxxxxx>
Subject: [cdt-dev] IParent
Reply-To: cdt-dev@xxxxxxxxxxx
Hi!
Maybe I'm just doing dumb things, but I am having to
create some model
elements that are used by various
views and tools that I don't want the
user to have to see because they
neither know nor care what they are.
For example, we copy executables sometimes to keep
them around for
navigation purposes through data
that does not go "completely stale" on a
build boundary. I don't want these
executables to show up in launch
selections or the CView but I do
want them represented in the core model.
Suggestions on what changes to make to do this? Is
this generally
interesting or are we out there in
our own little world?
Thanks!
-Chris
--__--__--
Message: 4
Date: Mon, 07 Apr 2003 12:55:16
-0700
To: cdt-dev@xxxxxxxxxxx
From: Chris Songer
<songer@xxxxxxxxxxxxx>
Subject: Re: [cdt-dev] NT
Launch/Build Abort
Reply-To: cdt-dev@xxxxxxxxxxx
At 03:07 PM 4/7/2003 -0400, you wrote:
>Some other possibilities:
>- It is a little vague in my
memory, but I do remember that you can tell gdb
> not to hold a
write access when debugging. Not sure it that will solve
> the problem.
>
>- Another possibility is to
create a Session property on the project
> that the builder
could check before building.
>
>- The debugger could make a
copy of the executable before running.
>
>But all the solutions are messy
and you do not want to push this
>on other platform less
brain-d^H^H^H^H^H^H^H .. susceptible to this
>behaviour.
All good suggestions.
I do think that the feature can stand on its own as an
option for non-NT
platforms. It can be confusing to
have running launches on stale builds and
our usability testing has shown
that it's vary common for new users end up
with lots of debugger sessions
running.
Having those cleaned up on rebuild may be desirable
behavior to some folks.
Thanks!
-Chris
--__--__--
Message: 5
Subject: Re: [cdt-dev] IParent
To: cdt-dev@xxxxxxxxxxx
Date: Mon, 7 Apr 2003 16:36:35
-0400 (EDT)
From: "Alain Magloire" <alain@xxxxxxx>
Reply-To: cdt-dev@xxxxxxxxxxx
>
>
> Hi!
>
> Maybe I'm just doing dumb
things, but I am having to create some model
> elements that are used by
various views and tools that I don't want the
> user to have to see because
they neither know nor care what they are.
>
> For example, we copy
executables sometimes to keep them around for
> navigation purposes through
data that does not go "completely stale" on a
> build boundary. I don't want
these executables to show up in launch
> selections or the CView but I
do want them represented in the core model.
>
> Suggestions on what changes to
make to do this?
> Is this generally
> interesting or are we out
there in our own little world?
If you need to inspect a executable, you could use the
binary parser directly. It is
better in the head branch
since we have now an extension
point and a
CCorePlugin.getBinaryParser(ICProject);
in the CDT_1_0_1, you will have to explicitely chose
one(ELF, PE).
Copy the file in /tmp/bin.tmpfile
Maybe for the future we could have an "in
Memory" executable
or working copy.
--__--__--
Message: 6
From: Sebastien Marineau
<sebastien@xxxxxxx>
To:
"'cdt-dev@xxxxxxxxxxx'" <cdt-dev@xxxxxxxxxxx>
Date: Tue, 8 Apr 2003 09:38:25
-0400
Subject: [cdt-dev] Conference call
minutes, April 3rd CDT call
Reply-To: cdt-dev@xxxxxxxxxxx
CDT monthly conference call, held April 3rd 2003 at
11AM EST.
Present:
QNX
Sebastien Marineau
Mikhail Khodjanis
Judy Green
Alain Magloire
Thomas Fletcher
Redhat
Phil Muldon
Rick Mosley
Tom Tromey
Timesys
Samm Rob
Rational
Michel Paquet
Dave Daoust
Doug Schaefer
John Camelon
Andrew Niefer
Hoda Amer
Sean Evoy
Bogdan Gheorghe
Tanya de Sousa
Cory Bialowus
Martin Lescuyer
1. Update from participants
- QNX is putting out an update on Momentics 6.2.1 with
the latest CDT 1.0.1
- New members have been added to
the Rational CDT team
- Work is continuing at Redhat on
Eclipse plugins for Linux development
2. Embedded systems conference BOF
Eclipse will be holding a birds of a feather session
at the San Francisco
embedded systems conference (April
24th). We are looking for participants,
as well as contributors to give 15
minutes technical presentations/demos
at the BOF. (Subsequent to the
call, Timesys indicated they would be
participating and giving a quick
talk/demo at the BOF). I'll be posting the
details to the list, and we hope
many of you will be able to join us.
3. CDT 1.1 update
The discussion for the CDT 1.1 release centered around
the core and debug
features,
as well as the timeline. It appears
that we are on track with the build
model
prototype, as well as build model
updates and parser. The new parser is
doing very
well, and received a lot of
positive feedback. Rational also mentionned that
there
is work going on with the indexer;
however, this is post-1.1. Alain will
sync
up with Rational on the indexer, as
he was also looking at making some
updates
to it.
The debug work is on track, with all planned features
commited. The debugger
works
with gdb 5.2.1 and 5.3. Montavista
submitted a patch for "gdbserver" target
support;
it was decided that we would
integrate this into the 1.1 release; Alain will
complete
that this week. Alain also made the
comment that he tried a gcj-compiled
Java program,
and was able to debug it in the CDT
debugger. Finally, Doug asked whether
any non-gdb
debugger had been implemented to
validate the CDI interfaces. As far as we
know, none
has been implemented yet.
In terms of timeframes, those set at the last
conference call still hold.
Feature
freeze is set for April 5th, with
bugfixes for the remainder of the month,
with a GA
target of the 30th of April. To
coincide with this, it was also suggested
that we
provide an update on the web page
highlighting the new features in CDT 1.1.
This
is to be discussed on the CDT
mailing list; Judy will update the web content
for
the 1.1 release.
4. Core/Debug work beyond 1.1
Very little was discussed beyond the work already
planned for CDT core and
debug. We
did set a target to make progress
on the target model; Thomas Fletcher will
try to
move this forward with a proposal
to the group by mid-May.
5. Switch to Eclipse 2.1 (feedback, issues)
The switch has been done, and has been quite seamless.
There is still work
to be
done in the CDT code to remove
warnings from deprecated interfaces, as well
as take
advantage of the new platform 2.1
features. This is ongoing work which will
be done
gradually.
Thomas asked when the breakage was done, in case
someone wanted to go back
to the 2.0-
compatible source. Alain will send
the exact date when the switch was done.
It was also
mentionned that making the CDT
source build with 2.0 is only a few lines of
change,
although the divergence will
increase as we take advantage of the new 2.1
APIs.
6. Communication and infrastructure
There were very few comments on this; the mailing list
are working out
pretty well,
and face-to-face meeting have
proven to be useful as well. The push to get
the CVS
infrastructure to generate
automatic patches sent to mailing lists is still
on,
and may be helped as the platform
team is also looking to do this.
7. Documentation/testing
Rational has taken the lead on a tutorial for CDT.
Tanya asked that people
forward any topics
or raw content to the cdt-doc
mailing list. It was decided that the "what's
new" type of
info would be put on the web site,
along with a possible section in the
docs.
On the testing front, there has not been any progress
on the UI automation
front.
Tensilica's test group was doing an
eval of different UI testing packages;
maybe
Chris Songer can email an update on
this to the list.
As for host platform testing, Judy brough up the
challenge with testing the
four
different supported hosts; we all
agreed that we would revisit this after
the 1.1
release, to try and spread the
load. Redhat proposed that they take on Linux
host testing.
8. Varia
CPPUnit was discussed again. Three main concerns with
it have been
expressed:
the fact that the CPPUNit framework
is LGPL, whether it is in fact the right
test
framework for C/C++, and the fact
that the CPPUnit project itself has been
inactive
for almost a year.
As Rational is doing some work on
CPPUnit, there is urgency in finding a
home for this
work. Michel and Sebastien will
work with John Duimovich over the next week
or two to
get this resolved.
Alain also brought up questions on the activity with
the 1.0.1 branch. It
was agreed that
we would stop updating it with
bugfixes over the next week, with all efforts
now focussed
on 1.1.
Sam asked about mixed Java/C debugging. This has been
discussed before as
one of the possible
long-term direction for the CDT
debugger, but no concrete work has been done
on this yet.
This is all I have, if I've forgotten anything or
misquoted anyone, please
let me know!
Thanks,
Sebastien
--__--__--
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/cdt-dev
End of cdt-dev Digest