On Jul 27, 2008, at 12:27 PM, Glynn Clements wrote:
Of course, some extra detection logic is needed to check for the
frameworks in /Library/Frameworks, then /System/Library/Frameworks.
configure doesn't autodetect paths, it only confirms that any paths
specified by the user work. If a path needs to be passed onto the
compiler or linker, the user has to supply it.
Well, for using the system paths, a path is still needed to set the
include flags, but not for the -F path.
Like -L flags, they are unnecessary for default system paths (/usr/
lib, or /System/Library/Frameworks and /Library/Frameworks), and can
cause trouble in the search order (on OSX) if used (you get the system
framework when you wanted a custom-build framework).
If we don't autodetect the path, but need a path for the headers, then
configure should not set -F if the user uses one of the system paths.
I take it that -framework is limited to the linker? I.e. the compiler
still needs explicit -I flags?
-framework is like -L, but for frameworks - yes, a linker flag only.
There is a way to include headers without -I flags, but it requires
changes to the sources, and it doesn't work for PrivateHeaders.
#include <Tk/tk.h>
looks for tk.h in the Tk.framework/Headers.
Also, the framework option should be rejected if opengl is not aqua.
It's still meaningful if OpenGL is disabled.
If linking tcltk is only for NVIZ, then tcltk should match the opengl
setting. The tcltk framework is always aqua, you can't build tcltk
x11 as a framework.
-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/
"We are at war with them. Neither in hatred nor revenge and with no
particular pleasure I shall kill every ___ I can until the war is
over. That is my duty."
"Don't you even hate 'em?"
"What good would it do if I did? If all the many millions of people of
the allied nations devoted an entire year exclusively to hating the
____ it wouldn't kill one ___ nor shorten the war one day."
<Ha, ha> "And it might give 'em all stomach ulcers."
- Tarzan, on war
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/grass-dev
