Hi Sean,
Ø
As long as they can add their
parser and the default parsers that ship with CDT to their manifest, then I
will be satisfied on this front.
That’s
true of my initial proposal, but easier with what I proposed in my most recent
reply. Let me know what you think.
Ø
Are you going to make the order
that parsers are specified in the manifest meaningful?
Yes, it would be an ordered list. The toolchain provider
should know the “preferred” order, and the user can change it if
they want.
Ø
I am just guessing at a
work-flow here, so bear with me. Imagine I have an implementer who just wants
to add one special build tool that needs a custom error
Ø
parser. As long as they can add
their parser and the default parsers that ship with CDT to their manifest, then
I will be satisfied on this front.
That’s a good question. My
understanding of the Standard Make functionality (I could be wrong…) is
that the default list and order or error parsers is stored in the workspace
metadata, but if the user changes the list for a specific project, that is
stored in the .project file. I think that Standard Make and Managed Make
should be the same but I don’t have a strong opinion on what is the
correct behavior.
Thanks,
Leo
-----Original Message-----
From: cdt-dev-admin@xxxxxxxxxxx
[mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf
Of Sean Evoy
Sent: Thursday, March 25, 2004
9:38 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed
Make build system and Error Parsers
Leo,
I
could live with that. My only concern is that it sets the bar a little high for
toolchain implementers (maybe). The default behaviour will save the implementer
that doesn't read the documentation or does not want to write code to implement
a toolchain. I am just guessing at a work-flow here, so bear with me. Imagine I
have an implementer who just wants to add one special build tool that needs a
custom error parser. As long as they can add their parser and the default
parsers that ship with CDT to their manifest, then I will be satisfied on this
front.
Some
additional questions that have occurred to me in the last hour in no particular
order. Are you going to make the order that parsers are specified in the
manifest meaningful? From a team development perspective, would this
information need to be persisted in the .cdtbuild file? At first blush, I would
say no; the settings come from the toolchain specification itself, and if the
user changes something locally, those changes should be a workspace setting
rather than clobbering something that will be shared through the CM system by
all team members.
Sean
Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
"Treggiari, Leo"
<leo.treggiari@xxxxxxxxx>
Sent
by: cdt-dev-admin@xxxxxxxxxxx
03/25/2004 09:19 AM
Please
respond to
cdt-dev
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] Managed Make build system and
Error Parsers
|
|
Hi Sean,
I agree with everything you’ve said, except for one
thing (maybe…). My proposal is for the toolchain to specify the
full, default list of error parsers for a new Managed Make project, not to add
new error parsers to the list of “installed” error parsers.
If the toolchain does not specify the list of error parsers and for
existing Managed Make projects, the default list will be used (i.e. the current
behavior). Are you suggesting something different?
Thanks,
Leo
-----Original
Message-----
From: cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Sean Evoy
Sent: Thursday, March 25, 2004 8:20 AM
To: cdt-dev@xxxxxxxxxxx
Subject: RE: [cdt-dev] Managed Make build system and Error Parsers
Leo,
By all means, let's make this part of a toolchain specification. From the short
amount of time I spent in the error parser code area, my impression was that
the default behaviour of the core is a best-effort attempt to find the error
parser from a list of known parsers. That's why the managed build still has its
output parsed even though there is no formal UI support.
Basically, under your proposal the manifest would supply zero or more error
parsers to that list through the managed build system. We would need to expose
this list to the user through the UI, implying a new property page (or a tab on
the managed build property page, or some error parser browse button, or...), a
preference page, and a new tab on the new project wizard. Compatibility will
not be an issue (from what I can see) since the system just adds error parsers.
I would think that at some point, there may be a request for some way to
override or remove known parsers, but that can be deferred. The default in the
absence of any new definitions is to use the default list, only now the user
will be able to reorder or remove some if that is what they want.
Sean Evoy
Rational Software - IBM Software Group
Ottawa, Ontario, Canada
"Lott, Jeremiah"
<jeremiah.lott@xxxxxxxxxxx>
Sent by: cdt-dev-admin@xxxxxxxxxxx
03/24/2004 06:03 PM
Please
respond to
cdt-dev
|
|
To
|
<cdt-dev@xxxxxxxxxxx>
|
cc
|
|
Subject
|
RE: [cdt-dev] Managed Make build system and
Error Parsers
|
|
This looks good to me. My only question is about backward-compatability.
What will the behavior be for projects that are already created, but
don't have an error parser set? Also what is the behavior for targets in
the extension that don't have any error parsers associated with them?
Jeremiah Lott
TimeSys Corporation
-----Original Message-----
From: Treggiari, Leo [mailto:leo.treggiari@xxxxxxxxx]
Sent: Wednesday, March 24, 2004 6:04 PM
To: cdt-dev@xxxxxxxxxxx
Subject: [cdt-dev] Managed Make build system and Error Parsers
I was surprised to learn recently that the CDT Error Parser
functionality is not used in the same manner by the Standard
Make and Managed Make build systems. From what I can tell:
o Standard Make:
- Allows the user to set the default for error parsers to be
used and in what order in the Window -> Preferences ->
C/C++
-> New Make Projects -> Error Parsers tab.
- When a new Standard Make project is created, allows the user
to modify the default settings for the new project using the
same UI.
- Allows the user to change the settings for the project in the
project Properties using the same UI.
- During a build, uses the project settings to determine which
error parsers to invoke and in what order.
o Managed Make:
- Doesn't do any of the above.
- During a build, uses all error parsers and I don't think there
is any way to control the order.
I sent mail to Sean a couple of days ago asking if he was in favor
of me investigating adding the error parser functionality to the
Managed Make build system, and he said OK. Having investigated
further, I've decided that the Managed Make support should be
implemented somewhat differently.
The per-project support should be the same - that is, it can be set
during project creation and changed by editing the project properties.
The difference would be in the project default. It
seems to me to be more appropriate for each "target" (or "tool
chain") being defined for the Managed Make build system to specify
the default list and order of the error parsers needed by the
"tool chain". This could be specified by each "tool
chain" in the
plugin.xml file where the information for the "tool chain" is
provided (for example, the "binary parser" and the command line
options.
Comments?
Leo Treggiari
Intel Corp.