[CMake] Re: framework search order

[E. Wing]

> Also, it would seem that ~ and /Network are not even
> supposed to be used:

As for ~ and /Network, Apple says you shouldn't use them, but they are
used a lot by developers (at least the first one is).  I think the
document is emphasizing end-user deployment practices and doesn't
really address the development side.

~/Library/Frameworks is extremely important to developers and people
that don't have Administrator access to install things to
/Library/Frameworks. The Xcode Framework template actually sets the
"Installation Directory" to $(HOME)/Library/Frameworks so Apple is
violating this policy themselves and passing it on to all developers.
I think Apple does this because it is not guaranteed that you have
write permission to /Library/Frameworks.

But it is also useful when you are developing/debugging a framework
that you already installed on the main system, but don't want to
mess-up other users that might be also working on your system. This is
a way you can work in a sand box. I suppose when we do final
deployment, we change the installation directory to something more
sensible. But as developers, it would be very handy to have CMake to
support this directory.

And of course on the deployment side, when not bundling the framework
inside an app for various reasons, we know that not all users have
Administrator access to install to /Library/Frameworks, so we tell
users to install to ~/Library/Frameworks if they don't have access to
/Library/Frameworks.

As for /Network/Library/Frameworks, this one is probably optional.
While I don't think it would hurt to include it, I don't think it is
used frequently so people probably won't miss it. However, I don't
work in large networked environments. I could imagine a scenario where
a medium/large-size mac development group has created a shared network
mount, and developers share libraries they develop by placing them in
/Network/Library/Frameworks so distribution to every developer machine
every time the framework is updated doesn't have to be done. But I've
never worked in setup like this so I don't know if it is actually done
this way.

> Looks like the search order used by gcc is:
>
> Framework search starts here:
> /System/Library/Frameworks
>  /Library/Frameworks

Interesting. The /System/Library/Frameworks is searched before
/Library/Frameworks for gcc, but the runtime search is the opposite
order. The runtime search order listed in the second document is what
I'm used to because this is what I see experimentally when I run my
stuff in those rare cases I've had to override a System framework:
1) The explicit path to the framework that was specified at link time.
2) The /Library/Frameworks directory.
3) The /System/Library/Frameworks directory


I think I was not bitten by the inconsistency between the two search
orders for two reasons:
1) The ABI didn't change in the replacement framework.
2) When you use a framework in Xcode, you usually explicitly add it to
the project using the Groups and Files panel so it has a full path to
it and invokes the -F flag so it is not up to the gcc default search
order.


But the Apple document seems wrong or incomplete on a couple of points
too. First, for compiling, remember that /Library/Frameworks is no
longer automatically searched by gcc when the Universal SDK is
enabled. (And all the other directories are remapped to the SDK.)

Second for runtime search paths, Apple didn't mention
~/Library/Frameworks which I know for a fact gets searched from
experimental tests I've run.

So the order is actually:
1) The explicit path to the framework that was specified at link time.
2) The ~/Library/Frameworks directory.
3) The /Library/Frameworks directory.
4) The /System/Library/Frameworks directory.


I never tested /Network/Library/Frameworks, but based on the sandbox
override methodology I described, I inferred that the search order
would look like:
1) The explicit path to the framework that was specified at link time.
2) The ~/Library/Frameworks directory.
3) The /Library/Frameworks directory.
4) The /Network/Library/Frameworks directory.
5) The /System/Library/Frameworks directory.


So I'm thinking that for CMake, you should actually make the compile
search order match the runtime search order as I had suggested before:
1) The ~/Library/Frameworks directory.
2) The /Library/Frameworks directory.
3) The /Network/Library/Frameworks directory.
4) The /System/Library/Frameworks directory.

Almost nobody overrides the System frameworks so this issue will
almost never come up, so putting /System last probably won't hurt.
Usually the source code is not open so you can't replace the
frameworks. Of those you can get source code for, generally it's
really extreme circumstances that somebody would take on the
responsibility of bypassing a system framework. (OpenAL happens to
meet that criteria, but it might be the only one.) So anybody who puts
a replacement system framework in should know what they are doing and
means to override it.

In these cases, the sandbox technique is very convenient to have, so
it would be nice to CMake just support this out of the box and match
the runtime search order. Furthermore, since you use the -F for
everything except for System frameworks anyway, nothing else is ever
really left to the gcc default anyway.

Thanks,
Eric