Re: [cdt-dev] Include paths for GCC and the indexer

[Doug Schaefer <cdtdoug@xxxxxxxxx>]

I have nothing to offer but encouragement. There is a long outstanding bug on this from other Mac users. Our friend Greg Watson was even invovled at one time I believe. Right now, I don't consider that we have first class Mac support until this is resolved. Unfortunatley, I don't have a Mac to help with.

On Fri, Jul 3, 2009 at 1:29 PM, Alex Blewitt <alex.blewitt@xxxxxxxxx> wrote:

I'm trying to solve an issue in ObjectivEClipse:

http://code.google.com/p/objectiveclipse/issues/detail?id=21

Basically, the problem is that in an Objective C code, the concept of 'frameworks' largely replace the concept of libs, but affect their on-disk format. For example>

#import <Foundation/Foundation.h>

is logically the same as

#import "/System/Library/Frameworks/Foundation.framework/Headers/Foundation.h"

This is picked up automatically by the compiler and linker (when -framework Foundation is added).

However, CDT has include paths and doesn't understand how to find <Foundation/Foundation.h>, largely because there isn't a 'Foundation' directory with a Foundation.h in it.

I suspect the same is true of #include as well (though #import is more common in ObjectiveC).

What would be the best way of trying to hook in the resolution of these directories? Is there some kind of extension point which can modify/contribute inclusion paths? Ideally it would be good to let GCC handle it, but being able to have some kind of project-defined {platform} that could then be searched to resolve #import <a/b.h> headers, that would be good.

Alex

Here's Apple's man page describing the use of -F

      -Fdir
          Add the framework directory dir to the head of the list of directories to be searched for header files.  These
          directories are interleaved with those specified by -I options and are scanned in a left-to-right order.

          A framework directory is a directory with frameworks in it.  A framework is a directory with a "Headers" and/or
          "PrivateHeaders" directory contained directly in it that ends in ".framework".  The name of a framework is the
          name of this directory excluding the ".framework".  Headers associated with the framework are found in one of
          those two directories, with "Headers" being searched first.  A subframework is a framework directory that is in
          a framework's "Frameworks" directory.  Includes of subframework headers can only appear in a header of a
          framework that contains the subframework, or in a sibling subframework header.  Two subframeworks are siblings
          if they occur in the same framework.  A subframework should not have the same name as a framework, a warning
          will be issued if this is violated.  Currently a subframework cannot have subframeworks, in the future, the
          mechanism may be extended to support this.  The standard frameworks can be found in
          "/System/Library/Frameworks" and "/Library/Frameworks".  An example include looks like "#include
          <Framework/header.h>", where Framework denotes the name of the framework and header.h is found in the
          "PrivateHeaders" or "Headers" directory.

      -iframeworkdir
          Like -F except the directory is a treated as a system directory.  The main effect is to not warn about
          constructs contained within header files found via dir.

_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev