William Kyngesburye wrote: > >> The main focus of this is the bundling step in the OSX app makefile. > >> To make sure that the configured tcltk is available to nviz, and to > >> avoid confusion with the system tcltk at runtime (which is where > >> Michael was having problems), I bundle tcltk into the app package. I > >> thus need to know the version for copying tclsh, wish, the library > >> and > >> tcl library folder, all of which have the version in the name, and by > >> default tcltk doesn't install unversioned symlinks. > > > > Ugh; I really think Tcl/Tk should be a separate package. > > > > If there are Tcl/Tk packages available from third parties, I think > > that you should just point people to one of them. If there aren't, > > then provide one, and we can put it on the GRASS site (we already > > provide a Tcl/Tk package for Cygwin, as Cygwin's version is broken). > > Well, another part of the need to know the version, is user > convenience and the way the OSX app works. > > The application doesn't have access to the user shell initialization, > so it won't see any of their .bash_profile (or other) settings. > (There is a way to set env vars for aplications, but most users don't > know about that, and I would like startup to be as simple as possible.) > > I know there is .grass.bashrc, but setting GRASS_WISH there doesn't > work for the first GUI screen because grass.bashrc is read after that > starts. > > For the tcltk install, Apple includes symlinks for tclsh and wish, but > the default source build only has tclsh8.x and wish8.x, so I at least > need the version to set GRASS_WISH in the OSX app startup.
Even so, you need to know the version that's installed on the target system, not on the build system. If you want to autodetect wish, do it in Init.sh, not in configure. Libraries and headers have to be detected prior to compilation, as the code won't compile without them, let alone run. But an interpreter isn't needed until run time (we install gis.m and wxGUI regardless of whether you have Tcl/Tk or Python installed on the build system). > I found another tcltk install layout issue that is causing me trouble > - with a source framework build no library symlinks are installed > (Apple adds convenient /usr/lib symlinks to the frameworks), so > current library detection in configure is meaningless, though required > for the tests to succeed (configure needs an option for tcltk aqua > detection). Can you elaborate? > The problem, even if a tcltk aqua option is added, is that wish and > tclsh are still installed in /usr/local/bin, not in the frameworks, > and I have no way of knowing they are there since there is nothing > stored in the framework telling me so. At compile time, you don't need to know that they're there. At compile time, they shouldn't actually even need to be there. > Two possibilities: > > - add a --with-tcltk-bin option > > - /usr/local/bin/wish is an odd one - wish does exist in the > framework, but /usr/local/bin/wish is a shell script that executes the > framework wish, not a symlink. This could be executed directly by > GRASS, and thus automatically configured. > > And, I don't see tclsh used in any of the GRASS code. Is tclsh a > shell for executing tcl (non-gui) scripts? Does anyone use it? Can > we ignore it? (and users can configure it themselves in grass.bashrc > if they ever need it.) Yes, don't know, and yes. > So, after all that, I see two aditions needed for configure: > > - set the tcltk version in platform.make For what purpose? The version is only needed in order to determine the compilation and linking switches. Once those are determined, you don't need to know how it got there. > - add a tcltk aqua option, much like what we do for opengl. And it > would have to be dependent on opengl=aqua. > > It would have to detect the active framework by looking in /Library/ > Frameworks first, then /System/Library/Frameworks. Or possibly accept > a user path (reuse --with-tcltk-libs, or have a separate --with-tcltk- > framework), which would set TCLTKLIBPATH = -F/user/path. > > The framework path (detected or user), would be used to set the > include paths: > > -I$path/Tcl.framework/Headers -I$path/Tk.framework/Headers -I$path/ > Tk.framework/PrivateHeaders > > And verify that the needed tkMacOSXInt.h is in one of those. > > TCLTKLIBS will always be: > > TCLTKLIBS = -framework Tcl -framework Tk I have added a --with-tcltk-framework= switch. If used, it sets TCLTKLIBPATH, TCLTKLIBS and TCLINCDIR as suggested above, and --with-tcltk-{libs,includes}= are ignored. I can't confirm whether it works, only that it doesn't break anything when not used. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-dev