[GRASS-dev] TclTk linking in GRASS 6.4

GRASS GIS GRASS GIS developer
1

Trying to understand the linking of TclTk in GRASS 6.4... I was poking around and noticed that libgrass_form itself does not link TclTk, and it appears it just creates form content in text and html. This content can be displayed with TclTk by the "form" applet, which does link TclTk, or in the console like with v.what, which does not link or use TclTk.

Is this the general case then - none of the grass libraries link or use TclTk directly, just some applets (like form) and modules (like NVIZ) do?

If so, I need to rethink my OS X arch substitutions to handle 32bit-only TclTk in 64bit GRASS.

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

Earth: "Mostly harmless"

- revised entry in the HitchHiker's Guide to the Galaxy

2

William wrote:

Trying to understand the linking of
TclTk in GRASS 6.4... I was poking around and noticed
that libgrass_form itself does not link TclTk, and it
appears it just creates form content in text and html.
This content can be displayed with TclTk by the "form"
applet, which does link TclTk, or in the console like with
v.what, which does not link or use TclTk.

Is this the general case then - none of the grass libraries
link or use TclTk directly, just some applets (like form)
and modules (like NVIZ) do?

no answer for you, just fyi see also 'd.what.vect -e' and
'g.mapsets -s' for common compiled C modules calling tcl/tk
forms.

regards,
Hamish

3

William Kyngesburye wrote:

Trying to understand the linking of TclTk in GRASS 6.4... I was poking
around and noticed that libgrass_form itself does not link TclTk, and
it appears it just creates form content in text and html. This content
can be displayed with TclTk by the "form" applet, which does link
TclTk, or in the console like with v.what, which does not link or use
TclTk.

Is this the general case then - none of the grass libraries link or
use TclTk directly, just some applets (like form) and modules (like
NVIZ) do?

Correct.

lib/form consists of the "form" program, a custom Tcl/Tk interpreter
which adds a few commands for interfacing with the GRASS DBMI library,
and a library which spawns the form program and feeds it a mixture of
Tcl/Tk code and HTML.

NVIZ consists of a custom Tcl/Tk interpreter which adds commands for
interfacing with the OGSF library, plus a significant amount of Tcl/Tk
code which uses the custom interpreter.

v.digit also links against Tcl/Tk (note that it has its own embedded
copy of the form library).

If so, I need to rethink my OS X arch substitutions to handle
32bit-only TclTk in 64bit GRASS.

In theory, it should suffice to build the two interpreters
($GISBASE/bin/nviz and $GISBASE/etc/form/form) plus v.digit as 32-bit
executables.

--
Glynn Clements <glynn@gclements.plus.com>

4

On Apr 3, 2013, at 10:13 PM, Hamish wrote:

no answer for you, just fyi see also 'd.what.vect -e' and
'g.mapsets -s' for common compiled C modules calling tcl/tk
forms.

On Apr 4, 2013, at 6:16 AM, Glynn Clements wrote:

William Kyngesburye wrote:

Trying to understand the linking of TclTk in GRASS 6.4... I was poking
around and noticed that libgrass_form itself does not link TclTk, and
it appears it just creates form content in text and html. This content
can be displayed with TclTk by the "form" applet, which does link
TclTk, or in the console like with v.what, which does not link or use
TclTk.

Is this the general case then - none of the grass libraries link or
use TclTk directly, just some applets (like form) and modules (like
NVIZ) do?

Correct.

lib/form consists of the "form" program, a custom Tcl/Tk interpreter
which adds a few commands for interfacing with the GRASS DBMI library,
and a library which spawns the form program and feeds it a mixture of
Tcl/Tk code and HTML.

NVIZ consists of a custom Tcl/Tk interpreter which adds commands for
interfacing with the OGSF library, plus a significant amount of Tcl/Tk
code which uses the custom interpreter.

v.digit also links against Tcl/Tk (note that it has its own embedded
copy of the form library).

If so, I need to rethink my OS X arch substitutions to handle
32bit-only TclTk in 64bit GRASS.

In theory, it should suffice to build the two interpreters
($GISBASE/bin/nviz and $GISBASE/etc/form/form) plus v.digit as 32-bit
executables.

I did a test (changing the makefiles) with a 64bit d.what.vect and libform and 32bit form. Still works - 64bit d.what.vect/libform has no problem spawning a 32bit form.

The main change needed then is adding a custom form.o compile target to libform makefile so that it can have separate CFLAGS from the default .o target. I hope this isn't a problem (I cut-n-paste from rules.make plus a couple changes).

-----
William Kyngesburye <kyngchaos*at*kyngchaos*dot*com>
http://www.kyngchaos.com/

First Pogril: Why is life like sticking your head in a bucket filled with hyena offal?
Second Pogril: I don't know. Why IS life like sticking your head in a bucket filled with hyena offal?
First Pogril: I don't know either. Wretched, isn't it?

-HitchHiker's Guide to the Galaxy