[GRASS-dev] debugging nviz with TclTk 8.5 aqua

[Michael Barton]

AFAICT, the only things of TclTk that actually get into the Mac binary  
for GRASS proper are the ancient BWidgets folder, which goes into all  
GRASS distributions, a copy of tclsh8.4 that doesn't seem to get used  
for anything, and copies of wish. Currently, my GRASS 7 binary, using  
TclTk aqua 8.5 has wish8.5 and wish8.4; GRASS_WISH is set to one or  
the other of these by grass.sh in $GISBASE. If I put in the x11  
version of wish8.4 and change the settings for GRASS_WISH in grass.sh,  
I can get an x11 version of the GUI.

There are tcl and tk directories in in %GISBASE/lib, along with  
libtcl8.4.dylib and libtk8.4.dylib. There are also some tcltk *.h  
files in $GISBASE/include. AFAICT, these are complete unused at least  
on my Mac. I can throw them away with no effect, regardless of whether  
I switch to wish 8.5 aqua or 8.4 x11. Are these used by any other  
system? While my aqua version of TclTk 8.5 is visible to my system,  
8.4 for x11 is hidden away in /usr/local/tcltk and not in my path--in  
GRASS or outside of it. So I don't see how GRASS can find any files in  
that directory.

In sum, the GRASS TclTk GUI seems to ONLY need wish of one flavor or  
another to run. So all that is needed is to include all 3 wish  
versions, default to one and have a Mac script that will let the user  
change to another one if desired. This is easy for all of GRASS except  
NVIZ.

NVIZ seems to use its own version of wish that must be coded into a C  
module somewhere. I certainly can't find it. But must be finding wish  
somewhere. If that path could be redirected to whatever GRASS_WISH is,  
then both GRASS and NVIZ could be in sync. The only fly in this  
ointment would be if Togl must have the same version of wish available  
(somewhere) that it was compiled against AND needs other TclTk files  
in addition to wish.

MIchael

On Jul 26, 2008, at 3:59 PM, Glynn Clements wrote:

>
> 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 <glynn at gclements.plus.com>