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 
We can have cygwin toolchain, but it does not apply to error parsers... Should we create cygwin gcc error parser?

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

Back to the top