I don't mean that we should ignore stdout. I just say that all errors
outputed to stderr. Is it correct or it isn't. Besides that, we can
implement tis as an option and switch it on or off depending on
toolchain.
On 29/01/2009 5:12 PM, Schaefer, Doug wrote:
Actually, I think we also scan
the output of make to guess at the current directory. I'm pretty sure
that's stdout.
D
But is that guaranteed to be
true, i.e., that compile errors never get spit out to stdout? I have a
foggy recollection that there was a compiler out there that used
stdout. But maybe that's just revisionist history. Anyone else seen one?
Doug.
I think we can improve situation with any error parser if we feed it
with stderr output only. All errors (the only task of any error parser
is to extract errors) are located in stderr, and in average case
stderr much smaller than stdout, which means that parser does a lot of
unnecessary work. There is one exception about stdout: it has to
provide information about current working directory. But this is just a
small part of work error parsers do now.
Alex.
On 29/01/2009 2:13 PM, Andrew Gvozdev wrote:
On Thu, Jan 29, 2009 at 1:37 PM, Elena
Laskavaia <elaskavaia@xxxxxxx> wrote:
We can have cygwin toolchain, but it does not
apply to error parsers... Should we create cygwin gcc error parser?
Then we need also cygwin linker error parser, cygwin make
error parser and assembler? I think that the right solution would be
user-configurable Regex error parser and let the users loose.
Andrew
Schaefer, Doug wrote:
>From my perspective, I'm in favor of
completely removing cygwin support
from the CDT core. We should be treating cygwin as a toolchain with the
right plug-in architecture to support it. This issue has been brought up
numerous times and it would be great to clean this up.
As the quasi-owner of CDT for Windows, I'll take that action and try to
work it into my schedule. But I'd like to hear others opinions on that
before I get to far.
Cheers,
Doug.
-----Original Message-----
From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Elena Laskavaia
Sent: Thursday, January 29, 2009 9:52 AM
To: CDT General developers list.
Subject: Re: [cdt-dev] Error parsers, slowness and cygwin
In this case it can resolve it right when user select this action,
saves a lot of time during parsing...
Btw when this command was added? I think eclipse right now is smart
enough to open external location itself. At least it works from other
tools.
Andrew Gvozdev wrote:
I found out what it is. It is well hidden but
actually very
useful. In
Problems view - do right-click on the problem
marker and
choose "Open
external location". If the file exists on disk you
would be able to open it - even if it is not in the project and even if
outside of the
workspace. This option works specifically when the
file was
not found
in the workspace. Resolving cygwin path is an
extra nicety here.
Thanks for the suggestion, I was considering submitting a
patch or two
in this area.
Andrew
On Thu, Jan 29, 2009 at 9:29 AM, Elena Laskavaia
<elaskavaia@xxxxxxx
<mailto:elaskavaia@xxxxxxx>>
wrote:
I don't think anybody knows. If you know how to
optimize it just do
it (submit a patch). I somebody would scream
then we
can come up with
something else, otherwise we can commit it in
6.0 and see if any
user would complain. One of the options to create a
user preference
to enable cygpath resolver,
otherwise do simple substitution like you suggested earlier.
Andrew Gvozdev wrote:
Hi,
Does anybody know the purpose of
ProblemMarkerInfo.externalPath?
Related to
ICModelMarker.C_MODEL_MARKER_EXTERNAL_LOCATION. CDT
takes some care to enter it in a few
places. This
field is not
being displayed in Problems view or Markers
view.
Doubleclick on
such entry (pointing outside of workspace)
has no
effect. Anyone
knows? There is another call to CygPath and
consequent
invocation of external program cygpath in
ErrorPattern (inside
getLocation call). Again, this is called
for each
line where it
cannot resolve file name in order to
populate the field
"externalPath". Is it important to populate it with
translated
path or it is possible to relax this
requirement?
Andrew
On Thu, Jan 22, 2009 at 11:38 AM, Andrew Gvozdev
<angvoz.dev@xxxxxxxxx <mailto:angvoz.dev@xxxxxxxxx>
<mailto:angvoz.dev@xxxxxxxxx
<mailto:angvoz.dev@xxxxxxxxx>>> wrote:
I refer to ErrorParserManager,
findFilePath(String filePath).
On Thu, Jan 22, 2009 at 11:04 AM, Elena Laskavaia
<elaskavaia@xxxxxxx <mailto:elaskavaia@xxxxxxx>
<mailto:elaskavaia@xxxxxxx
<mailto:elaskavaia@xxxxxxx>>> wrote:
Is this error parser? Or it is part
of the build?
Andrew Gvozdev wrote:
I was looking at the issue reported in
eclipse.tools.cdt
post
<http://www.eclipse.org/newsportal/article.php?id=17892&group=
eclipse.tools.cdt#17892
<http://www.eclipse.org/newsportal/article.php?id=17892&group=eclipse.
tools.cdt#17892>
<http://www.eclipse.org/newsportal/article.php?id=17892&group=
eclipse.tools.cdt#17892
<http://www.eclipse.org/newsportal/article.php?id=17892&group=
eclipse.tools.cdt#17892>>>
and how cygwin paths are
handling in the
code. Cygwin
utility "cygpath" is used to
translate
cygwin path to
windows, class
org.eclipse.cdt.utils.CygPath. While I
have
no doubt about its correctness, it
appears that running
separate external program for
each line
trying to map
(not
yet resolved) filename to cygwin path is a major
reason for
slowness of output parsing. A short test
of parsing
with and
without the translation attempt shows
slowness of x100
times. Is this the best way of
doing it? We use
eclipse to
compile projects remotely and some of
them are big
enough to
produce thousands of warnings where the
files are not
necessarily present on disk. Is
it
advisable to replace
using of the utility cygpath
with a
function which
would do
something like a simple translation from
"/cygwin/c/" to
"C:/" or so? Perhaps there is
already
such a function out
there somewhere?
Andrew
----------------------------------------------------------------------
--
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
<mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
<mailto:cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
----------------------------------------------------------------------
--
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto:cdt-dev@xxxxxxxxxxx>
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx <mailto: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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
|