Re: [cdt-dev] Influencing where CDT is looking for include paths

["Florian Kaltner" <metr0n@xxxxxx>]

Hi again! :-)

I agree with you. The scenario you described is working well!

Just opening an header file (in a #include directive) by hitting F3 is not working (what is fair, since no include paths are set).
I forgot to mention that i am not using the standard GCC toolchain but a proprietary one. So the include path settings are not necessary for bulding what is the reason i didn't set them until now.

So i am heading for one of  the following two solutions to influence where CDT looks for include files:

solution 1:
 * Put a listener on the Open file action
 * When a file is opened look for include statements (by using the AST)
 * if a include can not be resolved locally look into the pre-built Index if the file is there
 * If true, set an include path to that directory for that source file

solution 2:
Looking into the code of OpenIncludeAction.java i found out that a Scanner is questioned for include paths:

Line 104: IScannerInfo info = provider.getScannerInformation(res);
Line 110: IExtendedScannerInfo scanInfo = new ExtendedScannerInfo(info);
Line 130: String[] includePaths = scanInfo.getIncludePaths();

Now i am wondering if i can use a extension point to provide my own Scanner. I found the one called ScannerConfigurationDiscoveryProfile.exsd but i suppose this not what i am looking for?
(I didn't see how to implement my own ExtendedScannerInfo)

I would prefer this solution since i do not have to set include paths all the time.

Again any help is appreciated and thank you again for your response.

Maybe this it at least a pointer for someone else with a similar problem... ;-)

Thanks,
Florian

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

    hi Florian,

    This scenario works for me with CDT 5.0:
     (1) build pre-built content for an SDK
     (2) create a plug-in to make the pre-built index available to all
    projects
     (3) create a project lacking the appropriate include path settings
     (4) create a source file using types from the pre-built index, with no
    #include statements
     (5) use F3 on those types to navigate to the headers

    Its still a good idea to set up the include paths, as some features (F3 on
    #include) seem to
    need it. I can't see a reason not to set them up, even if the source tree
    is only partially
    present.

    If this doesn't help, please could you file a bug report* with the steps
    you've followed and
    the symptoms you're seeing?

    thanks,
    Andrew
    *https://bugs.eclipse.org/bugs/enter_bug.cgi?product=CDT


-- 
Ist Ihr Browser Vista-kompatibel? Jetzt die neuesten 
Browser-Versionen downloaden: http://www.gmx.net/de/go/browser