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

["Schorn, Markus" <Markus.Schorn@xxxxxxxxxxxxx>]

It should not be hard to make this work in CDT, I have commented on the
bug. See you there.
Markus. 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Greg Watson
> Sent: Thursday, February 19, 2009 4:55 PM
> To: CDT General developers list.
> Subject: Re: [cdt-dev] Include directories for Frameworks not 
> picked up
> Importance: Low
> 
> 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
>