[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Error parsers, slowness and cygwin
|
The big issue with cygwin is having to convert from Windows paths that
the CDT understands to cygwin paths, which are managed by cygwin1.dll.
I'd love to see a way of getting this conversion out of the CDT core so
that tools that don't need this conversion, like mingw and cross
compilers built with mingw, aren't affected by it.
Doug.
> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Elena Laskavaia
> Sent: Thursday, January 29, 2009 1:38 PM
> To: CDT General developers list.
> Subject: 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
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>
