William Kyngesburye 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.
AFAICT, it's like -l rather than -L. > 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. Are you sure that it doesn't work for PrivateHeaders; this suggests otherwise (under the documentation of -F): http://developer.apple.com/documentation/Darwin/Reference/ManPages/man1/gcc.1.html If it does work for PrivateHeaders, I would suggest using the framework syntax for the headers (then, -F should work for both the libraries and 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. Tcl/Tk isn't only for NVIZ. v.digit and the form library also link against it. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev