[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Managed Make build system and Error Parsers
|
And
just to throw a few cents in of my own, we should make sure that the ErrorParser
API is
going
to more or less remain as is for the 2.0 before we go and make changes. I
know that
Dave I
was looking at making changes in this area, though I _think_ that they were
mostly
internal changes and not changes with respect to the discovery and
manipulations of which
error
parsers are available.
Thanks,
Thomas
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
|
|
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.
