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