RE: [cdt-dev] Include directories for Frameworks not picked up

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

I don't think we made the include path resolution extensible like that,
but I haven't been in that code for a few years now. You'd still need to
pass along the concept of framework directory to that algorithm, so
you'd still need to extend the scanner info for that. This is specific
to gcc on Mac, so I'd prefer not to see it in the common gcc
interfaces/classes. 

No pointers where from me other than to look for IScannerInfo
references. Do they indexer guys have any suggestions?

Doug.

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
> Sent: Thursday, February 19, 2009 10:55 AM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Include directories for Frameworks not 
> picked up
> 
> Doug,
> 
> The only thing I can find is the standard -v option for gcc 
> which results in output like:
> 
> #include "..." search starts here:
> #include <...> search starts here:
>   /usr/local/include
>   /usr/lib/gcc/i686-apple-darwin9/4.0.1/include
>   /usr/include
>   /System/Library/Frameworks (framework directory)
>   /Library/Frameworks (framework directory) End of search list.
> 
> We could extend the parser so that it looks for the 
> "(framework directory)" text and then adds an include path 
> for each framework in this directory. However, this will 
> result in lots of include paths (there are 82 on my Mac), 
> which would be messy. I think a better approach would be to 
> translate the path when it is resolved. I presume that 
> somewhere there is a translation from "#include <x/y.h>" into 
> "/ usr/include/x/y.h" (or whichever header file resolves 
> first in the search order). So for Mac OS X, this would be 
> extended to translate the header path into 
> "/System/Library/Frameworks/x.framework/Headers/
> y.h".
> 
> Does this sound reasonable? Any pointers on how/where this 
> might be implemented?
> 
> Thanks,
> Greg
> 
> On Feb 18, 2009, at 11:09 AM, Schaefer, Doug wrote:
> 
> > I was wondering when you'd get back to that bug :).
> >
> > You probably need a custom way to specify the include path 
> to use this 
> > info. We generally use the output of gcc with certain 
> options to find 
> > out what it's built-in include path is. My memory is foggy 
> but I think 
> > there was special output from the Mac gcc compiler that listed the 
> > framework locations, sort of. You'd just need to extend the parser 
> > that collects that info to handle that.
> >
> > It's been a while since we talked about this but it would 
> be nice to 
> > get this resolved since I think this  is probably preventing CDT 
> > adoption on Mac. But I don't have one so I'm not sure ;)
> >
> > D.
> >
> >> -----Original Message-----
> >> From: cdt-dev-bounces@xxxxxxxxxxx
> >> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
> >> Sent: Wednesday, February 18, 2009 10:44 AM
> >> To: CDT General developers list.
> >> Subject: [cdt-dev] Include directories for Frameworks not picked up
> >>
> >> Hi folks,
> >>
> >> There's an issue with the scanner on Mac OS X because you 
> can have an 
> >> include like  "#include <OpenGL/OpenGL.h>", but instead of 
> the header 
> >> file being "/usr/include/OpenGL/OpenGL.h", it's actually "/System/ 
> >> Library/Frameworks/OpenGL.framework/Headers/OpenGL.h". 
> Even though "/ 
> >> System/Library/Frameworks" gets picked up in scanner 
> discovery, it is 
> >> not the path of the actual header directory, so the headers get 
> >> missed by the indexer.
> >>
> >> Any suggestions on the best way to fix this?
> >>
> >> A bug has been open on this for some time
> >> (https://bugs.eclipse.org/bugs/show_bug.cgi?id=69529
> >> ), but if someone who understands scanner discovery could 
> provide a 
> >> few pointers it would be appreciated.
> >>
> >> Thanks,
> >> Greg
> >> _______________________________________________
> >> 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
>