Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] Re: Include paths for GCC and the indexer

OK, so I found where this was happening and made a patch for CDT.

http://code.google.com/p/objectiveclipse/issues/detail?id=21
https://bugs.eclipse.org/bugs/show_bug.cgi?id=282413

This hard-codes /System/Library/Frameworks but shows that it's the right place to fix the problem. Ideally we should store some kind of generic concept of 'frameworks' for the project, and then use a system- compatible way of translating those into framework dirs.

Alex

On 3 Jul 2009, at 18:29, Alex Blewitt 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.




Back to the top