[CMake] Re: Mac OS X Framework support

E. Wing ewmailing at gmail.com
Fri Dec 23 18:15:19 EST 2005


> OK, this sounds good, although I think there needs to be someway
> to name the framework we are looking for in the FIND_PATH, although
> that would mean changing existing FIND_PATH calls, which we want to avoid.
> I am concerned that an exhaustive search of all found/installed frameworks
> for
> SDL.h may be slow.    Using FIND_LIBRARY to find a framework is easy because
> the name of the thing plus a .framework is the name of the framework.
> However,
> a call to FIND_PATH (foo.h)  gives us no information about what package
> foo.h is
> in, and requires a modification for the mac.   Any ideas?
>
> -Bill
>

Yeah, this could be tricky. I cannot think of any definitive ways of
dealing with this unless you change FIND_PATH. Maybe an optional
parameter that specifies the framework for those who care about
performance?

But, if you are willing to change FIND_PATH (or invent
FIND_INCLUDE_PATH), maybe the API can be refactored to realize that
somethings reside in "namespaces" (for a lack of a better term).

For example, OpenGL puts stuff in GL/
wxWidgets puts stuff in wx/
SDL puts stuff in SDL/ (usually)

So for OpenGL, the typical FIND_PATH looks something like this:
FIND_PATH(MY_INC_DIR GL/gl.h
/usr/local/include
/usr/include
/usr/X11R6/include
...
)

Notice that the "namespace" is part of the header string. Contrast
this to how we search for SDL.
FIND_PATH(MY_INC_DIR SDL.h
/usr/local/include/SDL
/usr/local/include/SDL11 # For FreeBSD
/usr/local/include/SDL12 # Just in case FreeBSD realizes we've been at
1.2 for years
/usr/local/include # Just in case SDL.h is not in a "namespace"
/usr/include/SDL
/usr/include/SDL11 # just in case
/usr/include/SDL12 # just in case
/usr/include               #just in case
...
)
Notice that we have a generally very nessy/verbose way of dealing with
the varying "namespaces" which hasn't even taken into account OS X
frameworks.

So what if did decide to change FIND_PATH, we could do it in a
universal way so all platforms benefit and not just for OS X
Frameworks' sake.

So I propose something like the following:
FIND_INCLUDE_PATH(MY_INC_DIR
    gl.h
    NAMESPACES  GL OpenGL
    FLAT_NAMESPACE_USAGE NO
    PATHS
    /usr/local/include
    /usr/include
    ...
)

And for SDL
FIND_INCLUDE_PATH(MY_INC_DIR
    SDL.h
    NAMESPACES SDL SDL11 SDL12
    FLAT_NAMESPACE_USEAGE YES
    PATHS
    /usr/local/include
    /usr/include
)

You can see particularly in the SDL case, the list of paths I have to
list becomes much shorter and nicer by a factor of 3 (or 4). This is
significant as there are more paths to search which I didn't list.


So in the first case (OpenGL), the FLAT_NAMESPACE_USAGE=NO informs the
API that your code uses the usage pattern: <Foo/bar.h> instead of
"bar.h".
Combined with NAMESPACES CMake will try looking for #include <GL/gl.h>
and <OpenGL/gl.h> against
/usr/local/include
/usr/include
and of course look for the frameworks
GL.framework
OpenGL.framework.

In the SDL case, the FLAT_NAMESPACE_USAGE=YES informs CMake the usage
pattern is "SDL.h". This flag also says the -I flag must be used
instead of -F for frameworks.
It will then look in
/usr/local/include/SDL
/usr/local/include/SDL11
/usr/local/include/SDL12
/usr/local/include # Maybe this too?
/usr/include/SDL
/usr/include/SDL11
/usr/include/SDL12
/usr/include
and of course look for the frameworks
SDL.framework
SDL11.framework.
SDL12.framework


Obviously, my terminology need to be cleaned up, and maybe the API
design could be cleaned up/streamlined, but I hope it gets the idea
across.


For not changing or adding a new API, I only have heuristics you might try.
You could first try to use the basename of the header as the Framework name:
If SDL.h, then look for SDL/SDL.h,
but this fails for things like
gl.h because it is in OpenGL.h
and fails even worse for things like PositionAttitudeTransform which resides in
<osg/PositionAttitudeTransform>

If CMake has any notion of state, then maybe if FIND_LIBRARY has
already been used, then you could search the libraries it has found
first.

Then you could try leveraging the Unix "locate" database. Then if you
are in Tiger and still haven't found anything, you could try a
Spotlight query (mdfind). However, I don't remember if Spotlight
indexes framework directories by default. (I changed the default
settings on my system so mine do get searched.)

CMake could also try keeping an internal OS X specific database of
/System frameworks which never change per OS major version. Most of
the frameworks reside here.

After this point, I think it becomes a brute force GLOB approach which
you mentioned in a following email which seems reasonable.


Thanks,
Eric


More information about the CMake mailing list