[CMake] Re: Frameworks and FIND_FILE

[E. Wing]

If you want to go this route, I think we can and should be more
clever/aggressive. Instead of requiring special framework keywords to
always being used, I think we can infer which version to use and will
usually be right. This at least gives a OS X a fighting chance of
working out of the box without the Find*.cmake authors being OS X
aware.


So in the scenario /System/Library/Frameworks/Bar.framework/Headers/Foo.h
(note I changed the framework name to Bar to give a little more
distinction, but this still works for Bar=Foo)

If the usage is
FIND_PATH(FOO Foo.h),
then use FOO=/System/Library/Frameworks/Bar.framework/Headers and
-I/System/Library/Frameworks/Bar.framework/Headers

If the usage is FIND_PATH(FOO Bar/Foo.h)
then use FOO=/System/Library/Frameworks/Bar.framework and -F/System/Library


I think this will cover the typical usage cases. But just in case
there is a corner case where somebody needs to do the opposite, having
an override for FRAMEWORK_INTERNAL and FRAMEWORK_EXTERNAL might be a
good idea:

# The overrides for each scenario:
FIND_PATH(FOO FRAMEWORK_EXTERNAL Foo.h),
FIND_PATH(FOO FRAMEWORK_INTERNAL Bar/Foo.h)


Also, just a note, you might want to use a heuristic first before
using the GLOB, particularly for  the FIND_PATH(FOO Foo.h) usage
scenario.
I'm worried there might be a case where Foo.h exists in multiple
frameworks. You probably should try locating a Foo/Foo.h first before
anything else.



The reason I suggested all the namespace stuff in the previous emails
was to handle the variations of "Bar" which is a more general problem
and not necessarily framework/OSX specific as I showed with the SDL11
problem with FreeBSD. This approach might be worth considering because
it is general enough to address a problem that affects all platforms.

Thanks,
Eric



On 12/26/05, Bill Hoffman <bill.hoffman at kitware.com> wrote:
> I can make FIND_FILE(FOO foo.h) find foo.h in installed frameworks,
> the globing approach works well, and is fast enough.
> However, I am not sure what to do with it.   I think there is not choice
> but to add some extra MAC specific syntax to FIND_FILE.
>
> Here is the problem, lets say we have this:
>
> /System/Library/Frameworks/foo.framework/Headers/foo.h
>
> So, we do this:
>
> FIND_PATH(FOO foo.h)
>
> I have no problem finding foo.h in foo.framework/Headers/foo.h.
> The question is what to do with it?
>
> As I see it my options for setting FOO are:
>
> 1. FOO=/System/Library/Frameworks/foo.framework
> If INCLUDE_DIRECTORIES see something like this, then it adds
> a -F/System/Library  instead of the usual -I.
>
> 2. FOO=/System/Library/Frameworks/foo.framework/Headers
> If INCLUDE_DIRECTOIRES sees this, it just adds a
> -I/System/Library/Frameworks/foo.framework/Headers
>
> However, previous emails show the problem with either of these assumptions,
> sometimes you want 1, and sometimes you want 2.  So, there will
> have to be specific syntax to take care of this.  However, this means
> that Find*.cmake authors will have to be Mac/Framework aware...
> It sounds like by default, cmake should do option 1.   This way existing
> Find*.cmake stuff will work if the code uses frameworks as indented on
> the Mac, no -I into framework guts, just -F and -framework.  This will
> avoid namespace problems.
>
> For case 2, we are going to have to tell FIND_PATH that it should return
> a path that is inside the framework structure.
>
> Something like this:
> FIND_PATH(FOO FRAMEWORK_INTERNAL foo.h )
>
> Which will use the same searching done in 1. but will return:
> FOO=/System/Library/Frameworks/foo.framework/Headers for the path.
>
>
> BTW, I just checked in some changes to FIND_LIBRARY that now
> make it framework aware, and it seems to work well.
>
> -Bill
>
>
>
>