Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [cdt-dev] Influencing where CDT is looking for include paths

Hi Andrew!

Thanks for your response!
I am aware that i am kind of abusing the pre-building index feature in a way it was not meant to be used.

The problem is, that the source which was used to build the PDOM takes to long if indexed locally.
In addition to that checking out the entire source is quite time-consuming.

So the idea was to use the prebuilt index to get code-assist features while not having the entire source stored locally. This works quite well so far.
The problem now is just that you don't want to navigate to every include file in order to open and view it manually.
(Since the files should be in the index and so it should be possible to get the path to them)
It would be nicer hitting F3 popping up a new editor window showing its content.

Is setting an include path the only way to do that?
Or can i influence the action triggered by hitting F3 somehow?


2008/6/26 <Andrew.Ferguson@xxxxxxxxxxx>:

    hi Florian,

     the pre-built indexes in CDT 4.0/5.0 are intended to address the use-case
    where the pre-built
    content is non-changing(*1) and disjoint (*2) from the workspace - e.g.
    SDK or library headers.

    In that scenario, references to types outside the workspace will be
    resolved to the pre-built content
    and navigation features will direct to file paths obtained from there when
    appropriate. This doesn't
    mean include paths should not be set up correctly in the project model -
    project builders
    will still need that information to correctly compile. You can do that


    > I am using a pre-built index file on a project which does not
    > contain all of the files which were indexed.
    > All of the files which where indexed are accessible through a
    > network filesystem.
    > Suppose the index contains a file "a.h" and "b.c" amongst other
    > source files and headers.
    > When I am copying b.c to my project (and nothing else of the full
    > project which was indexed) and in that file the header "a.h" is used
    > error markers are generated (i suppose this is the case since i have
    > no include path set which points to a location where "a.h" is
    > present) and i cannot open the header using F3.
    > Opening other classes which are not present in a local source file
    > but on the index works fine using F3 (the paths to the indexed files
    > are completed by a implementation of a IReadOnlyPDOMProvider) - its
    > just on the include paths where this fails.
    > Is there a possibility to take influence where CDT is looking for
    > includes? I thought about something like:
    >  * check for headers in a file
    >  * first look locally if the header is present in the include path
    >  * if not check the pre-built index if the file is present in it
    >  * if it's present in there use the file which was indexed
    > Would it then be possible to get rid of the errormarkers in the editor?
    > Hopefully someone can give me a pointer where to look at,
    > respectively if this is possible at all.
    > Thanks for your Help!
    > --
    > GMX startet Hier findest Du Leute mit Deinen Interessen!
    > Jetzt dabei sein:
    > _______________________________________________
    > cdt-dev mailing list
    > cdt-dev@xxxxxxxxxxx

     Symbian Software Ltd is a company registered in England and Wales
    with registered number 4190020 and registered office at 2-6
    Boundary Row, Southwark, London,  SE1 8HP, UK. This message is
    intended only for use by the named addressee and may contain
    privileged and/or confidential information. If you are not the
    named addressee you should not disseminate, copy or take any action
    in reliance on it. If you have received this message in error
    please notify postmaster@xxxxxxxxxxx and delete the message and any
    attachments accompanying it immediately. Neither Symbian nor any of
    its Affiliates accepts liability for any corruption, interception,
    amendment, tampering or viruses occurring to this message in
    transit or for any message sent by its employees which is not in
    compliance with Symbian corporate policy.
    cdt-dev mailing list

Psssst! Schon vom neuen GMX MultiMessenger gehört?
Der kann`s mit allen:

Back to the top