|
I
wasn't worried about you making changes, I was worried about things changing
underneath your
feet
=;-) I think that you should be safe however.
Thanks,
Thomas
Hi
Thomas,
I'm not planning on
making any changes to the existing functionality:
- The error parser
extension point
- The discovery of
error parsers
- The way that
Standard Make projects currently deal with error parsers (UI, invocation,
etc.)
I certainly will not
do so without consulting the mailing list.
Thanks,
Leo
-----Original
Message-----
From:
cdt-dev-admin@xxxxxxxxxxx [mailto:cdt-dev-admin@xxxxxxxxxxx] On Behalf Of Thomas Fletcher
Sent: Thursday, March 25, 2004 8:38
AM
To:
'cdt-dev@xxxxxxxxxxx'
Subject: 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.
-----Original
Message-----
From: Sean
Evoy [mailto:sevoy@xxxxxxxxxx]
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
|
|
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.
|
