[CMake] Re: Frameworks and FIND_FILE

[E. Wing]

> My concern here is what you said in an earlier email.  You said that
> when you attempted to just use -I for everything, you ended up with build
> errors, because there are .h files in packages with unsafe names:

Yes, there is a risk of name collision, but there is always risk of
name collision when using the form "Foo.h" on all platforms, and I
think the risk will be minimized since you are handling the flags
instead people like me hacking stuff to get frameworks to work.


>From what I've seen with most code is that they are typically written
on Linux or Windows first and then ported over to OS X. Nobody is
framework aware, but they shouldn't really need to be. Generally the
libraries already adopt a standard convention. With things like
wxWidgets or OSG, they write code like
#include <wx/wx.h>
#include <osg/Node>

This is supposed to work for all systems without any code changes and
this maps perfectly to the frameworks, and this was by design.



The other usage:
#include "SDL.h"
#include "lua.h"
always risks name collision. They may or may not place things in a
subdirectory like SDL/ or lua/, so you could potentially conflict with
stuff in other directories that are searched. This could happen on a
Linux system as well as OS X (regardless of frameworks).

But usually these libraries were smart enough to pick header names
that would never likely conflict with other components.



> As you said in an earlier email:
>
> >So my original thinking was, "Why not just use -I for everything
> >instead and ditch the -F flag". Well it doesn't work for the opposite
> >case.
> >

The reason I did this was because I didn't know how to get CMake to
invoke the -F flag for me so I thought I could get around it by
invoking the -I flag. This failed as discussed, but since you're
putting in native support for this, people won't be making this
mistake because they won't have to deal with this. My point about this
topic was you do have to handle the two separate cases because the -I
flag is not interchangeable with the -F flag. But based on usage
patterns, I think you can reasonably infer what to do. I'm optimistic
this will work.

I have a strong desire not to be permanently condemned to always be
fixing other modules. I would like at least the chance of something
working out of the box. I really believe this can work. So if not this
route, I would suggest going to the FIND_INCLUDE_PATH idea. At least
there's the chance that future modules will just work once this is
adopted (and potentially solve the other more general problem).

Thanks,
Eric