[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[cdt-dev] RE: cdt-dev Digest, Vol 16, Issue 51
|
Shaival Parekh
System Executive
KPIT Cummins Infosystems Limited.
Pune Tel : 91-20-25382358 Ext : 135
Visit us : www.kpitcummins.com
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of cdt-dev-request@xxxxxxxxxxx
Sent: Monday, June 26, 2006 6:30 PM
To: cdt-dev@xxxxxxxxxxx
Subject: cdt-dev Digest, Vol 16, Issue 51
Send cdt-dev mailing list submissions to
cdt-dev@xxxxxxxxxxx
To subscribe or unsubscribe via the World Wide Web, visit
https://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-owner@xxxxxxxxxxx
When replying, please edit your Subject line so it is more specific
than "Re: Contents of cdt-dev digest..."
Today's Topics:
1. Include path discovery hardcoded to use "gcc" (John Dallaway)
2. CDT 3.1 Call for Status (Doug Schaefer)
3. RE: Include path discovery hardcoded to use "gcc"
(Sennikovsky, Mikhail)
4. Re: CDT 3.1 Call for Status (Chris Recoskie)
----------------------------------------------------------------------
Message: 1
Date: Mon, 26 Jun 2006 11:53:34 +0100
From: John Dallaway <jld@xxxxxxxxxxxxxxx>
Subject: [cdt-dev] Include path discovery hardcoded to use "gcc"
To: cdt-dev@xxxxxxxxxxx
Message-ID: <449FBCAE.9080800@xxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
I'm looking at options for a fix for bug 117294:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=117294
Ideally, I would like to fix this by forcing the scanner to use the
user-specified compiler tool for the current managed build project (eg
"arm-elf-gcc") rather than using "gcc".
I have verified that I can hard code a new tool for scanning by
overriding the value of the fCompileCommand variable within
GCCSpecsRunSIProvider.initialize(), but there does not appear to be an
elegant way to access ManagedBuildInfo.getToolForSource() from here
without breaking the existing abstractions.
An alternative approach might be to generalize the "Discovery Options"
code and UI currently used by unmanaged make projects and use them also
for managed make projects. But the user would then have to specify the
compiler tool both in the build tools UI and in the discovery options
UI.
Is there a reason why the tool used for scanning was kept distinct from
the tool used for compiling within CDT?
Any other thoughts on the best way to address this bug would be most
welcome.
John Dallaway
------------------------------
Message: 2
Date: Mon, 26 Jun 2006 08:43:45 -0400
From: Doug Schaefer <DSchaefer@xxxxxxx>
Subject: [cdt-dev] CDT 3.1 Call for Status
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Message-ID:
<3518719F06577C4F85DA618E3C37AB9105B261B1@xxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset="us-ascii"
Hey gang,
As per our ramp down schedule, this morning's build is supposed to be
candidate build for CDT 3.1. Please report your go/no-go status for it.
The
Callisto train departs on Wednesday so I'd like to get this wrapped up
by
tomorrow if possible.
One troubling item is that we still have two defects open on 3.1. Chris
and
Mikhail K, do we need to hold up the release for these, or do you need a
rebuild?
ID
Assignee
Reporter
Status
TargetM
Summary
142465 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=142465>
Mikhail Khodjaiants
Anton Leherbauer
ASSI
3.1
Exception when expanding binary node in CView
148439 <https://bugs.eclipse.org/bugs/show_bug.cgi?id=148439>
Chris Recoskie
Mikhail Sennikovsky
ASSI
3.1
NPE in build/clean selected files functionality
Thanks!
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com <http://cdtdoug.blogspot.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://eclipse.org/pipermail/cdt-dev/attachments/20060626/075546e5/attac
hment.html
------------------------------
Message: 3
Date: Mon, 26 Jun 2006 16:46:02 +0400
From: "Sennikovsky, Mikhail" <mikhail.sennikovsky@xxxxxxxxx>
Subject: RE: [cdt-dev] Include path discovery hardcoded to use "gcc"
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Message-ID: <AFFB534DFDE16E44B5413E9F8B8E2AD201FA1A39@NNSMSX401>
Content-Type: text/plain; charset="us-ascii"
Hi John,
The scanner info provider command is not hard-coded actually.
You are able to define the custom Scanner Discovery Profile using any
tool(command) and associate it with your tool-chain definition via a
toolChain::scannerConfigDiscoveryProfileId attribute.
But I agree we should allow modifying the default profile settings for
the tool-chain.
I agree with your approach of having one and the same core and UI
representation of this functionality for the Managed and Standard make
and I think we should be able to do that having the tool-chain concept
introduced to the Standard Make as well that is planned as part of the
New Project Model in 4.0.
>Is there a reason why the tool used for scanning was kept distinct from
the tool used for compiling within CDT?
First of all there is a historical reason for this: the scanner info
provider mechanism is not part of the MBS functionality and knows
nothing about MBS tools. The other thing is that the scanner info
provider command can (theoretically) differ from the tool command used
for compilation, so we should not link them tightly with each other.
IMHO the easiest way to be used for now for solving this issue is to
allow using the Build Macros (Variables) in the profile definition.
This should allow the profile settings to be always consistent with the
tool settings, e.g. we could introduce the "ToolCommand" macro and then
use this macro in the scanner info provider command. This will guarantee
that the provider command will by default always be the same as the tool
command as well as will allow users to modify this behavior by
customizing the info provider command.
This approach can be already implemented with MBS, but once we have the
Build Macros (Variables) concept become part of the core, this approach
can be spread for both Standard and Managed make.
Mikhail
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of John Dallaway
Sent: Monday, June 26, 2006 2:54 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Include path discovery hardcoded to use "gcc"
I'm looking at options for a fix for bug 117294:
http://bugs.eclipse.org/bugs/show_bug.cgi?id=117294
Ideally, I would like to fix this by forcing the scanner to use the
user-specified compiler tool for the current managed build project (eg
"arm-elf-gcc") rather than using "gcc".
I have verified that I can hard code a new tool for scanning by
overriding the value of the fCompileCommand variable within
GCCSpecsRunSIProvider.initialize(), but there does not appear to be an
elegant way to access ManagedBuildInfo.getToolForSource() from here
without breaking the existing abstractions.
An alternative approach might be to generalize the "Discovery Options"
code and UI currently used by unmanaged make projects and use them also
for managed make projects. But the user would then have to specify the
compiler tool both in the build tools UI and in the discovery options
UI.
Is there a reason why the tool used for scanning was kept distinct from
the tool used for compiling within CDT?
Any other thoughts on the best way to address this bug would be most
welcome.
John Dallaway
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
------------------------------
Message: 4
Date: Mon, 26 Jun 2006 08:59:50 -0400
From: Chris Recoskie <recoskie@xxxxxxxxxx>
Subject: Re: [cdt-dev] CDT 3.1 Call for Status
To: "CDT General developers list." <cdt-dev@xxxxxxxxxxx>
Message-ID:
<OF84A40368.54BB549A-ON85257199.0047573F-85257199.00477645@xxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-1
I should have mine fixed by noon and I will ask for a rebuild for it
once
I'm ready.
===========================
Chris Recoskie
Team Lead, IBM CDT Team
IBM Toronto
http://www.eclipse.org/cdt
Doug Schaefer
<DSchaefer@xxxxxx
m>
To
Sent by: "CDT General developers list."
cdt-dev-bounces@e <cdt-dev@xxxxxxxxxxx>
clipse.org
cc
Subject
26/06/2006 08:43 [cdt-dev] CDT 3.1 Call for Status
AM
Please respond to
"CDT General
developers list."
<cdt-dev@eclipse.
org>
Hey gang,
As per our ramp down schedule, this morning?s build is supposed to be
candidate build for CDT 3.1. Please report your go/no-go status for it.
The
Callisto train departs on Wednesday so I?d like to get this wrapped up
by
tomorrow if possible.
One troubling item is that we still have two defects open on 3.1. Chris
and
Mikhail K, do we need to hold up the release for these, or do you need a
rebuild?
ID Assignee Reporter Sta Targe Summary
tus tM
14246 Mikhail Anton ASS 3.1 Exception when expanding
5 Khodjaiants Leherbauer I binary node in CView
14843 Chris Mikhail ASS 3.1 NPE in build/clean selected
9 Recoskie Sennikovsky I files functionality
Thanks!
Doug Schaefer, QNX Software Systems
Eclipse CDT Project Lead, Tools PMC member
http://cdtdoug.blogspot.com
_______________________________________________
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
End of cdt-dev Digest, Vol 16, Issue 51
***************************************
