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

I think that it is great that CDT supports cygwin and it would be sad to lose it. Having said that I agree that cygwin support should not be part of core. I believe it should be removed carefully piece-by-piece each time providing alternative for cygwin users.

Andrew

On Thu, Jan 29, 2009 at 11:42 AM, Schaefer, Doug <Doug.Schaefer@xxxxxxxxxxxxx> 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