Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Error parsers, slowness and cygwin

Yes, I want to take a look at how filenames are resolved and to rework it to more orderly processing. My most concern is proper resolution of duplicate names/partial paths with output like

src/mymodule/include.h:125: error insightful description
src/anothermodule/include.h:225: error another insightful description

and full paths arriving from remote compilation which need to be mapped to local files. We don't compile on cygwin or Windows but using cygwin unix utilities to support remote build as a part of our build system. And, well, I am using Linux Debian for smoke testing.

So far I got a bunch of test cases covering most of existing functionality in this area - before I started reworking - and interested in as many nut use cases as possible. I'll post the test cases when the use cases I know of are exhausted.


On Tue, Feb 3, 2009 at 4:26 PM, James Blackburn <jamesblackburn@xxxxxxxxx> wrote:
There are other issues with ErrorParserManager. One is created per
project, per build, and as part of it's construction it iterates over
and collects all the IResources in the project.  It does this on
_every_ build.  Apart from that it also gets the linked resources /
overlapping-projects story wrong.  If we defer to the centralised
ResourceLookup for most of this, we'd get this right for free IMHO.

Andrew Windows isn't my primary platform (though I do use it + Cygwin
for smoke-testing) so any contributions/ideas you have on that front
are appreciated.



On Thu, Jan 22, 2009 at 3:07 PM, Andrew Gvozdev <> wrote:
> I was looking at the issue reported in post 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
cdt-dev mailing list

Back to the top