[GRASS5] uploading your binaries

GRASS GIS GRASS GIS developer
,
1

I'm trying to figure out how (if?) we could easily provide the unix version of TclTk to Mac OS X users if they don't have a packaging system installed. I know, there is also the native Aqua Tcl/Tk they can install, but that doesn't work with a GRASS binary distribution that was compiled for the UNIX model of TclTk. Many users will have TclTk installed as part of some packaging system like fink, or could add it to their installation relatively easily, but the idea here is that relative newcomers to Unix software on the Mac platform might be able to install a grass binary distribution with a minimum of "overhead" requirements. We've handled GDAL by including a shared library in $GISBASE/lib, Paul has mentioned that this could be done with libproj too, now I'm wondering about Tcl/Tk.

I figured that the simplest way might be to compile it and then provide a tarball of the installed files with instructions on how to expand it on to the user's system, with a recommendation that it go under /usr/local - this keeps things pretty simple.

I imagine this would work, but it got me thinking.... TclTk only uses the bin, include, lib, and man directories for installation - if it was expanded into the GISBASE directory, would that work? The idea would be to ensure GRASS/tcltkgrass/NVIZ would work on the system with minimum change to the rest of the user's system. And then we also make sure that the version of tcl/tk matches what the nviz compilation is expecting, and don't have to give instructions re: changing LD_LIBRARY_PATH, etc...

Or is that like playing with a hornet's nest? I vaguely recall discussion of problems with including tcl headers in the distribution, but don't remember the context and don't really trust the memory.

Thanks,
Scott

Begin forwarded message:

From: Michael Barton <michael.barton@asu.edu>
Date: March 2, 2004 13:11:34 EST
To: Scott Mitchell <smitch@mac.com>
Subject: Re: uploading your binaries

Scott,

Do you have any idea where to get a packaged version of tcltk that we could include in a Mac OSX package to avoid having to upload fink (as much as I like fink)?

Michael

On Tuesday, March 2, 2004, at 11:04 AM, Scott Mitchell wrote:

The version I now have should be at least clean from the internationalization library, and now I also have some on my portable that are compiled against GDAL1.2.0 ... so I guess it would make sense for me to upload those ones, after the class I'm just now heading out to teach. I'm not sure how big the change is in GDAL, but vaguely recall a list message from Markus advising someone to use it, so there may be something important.

Cheers,
Scott

...

...
------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building (Office A209)
1125 Colonel By Drive, Ottawa, ON Canada K1S 5B6
+1-613-520-2600 ext 2695 Fax: 1-613-520-4301

2

Scott Mitchell wrote:

I'm trying to figure out how (if?) we could easily provide the unix
version of TclTk to Mac OS X users if they don't have a packaging
system installed. I know, there is also the native Aqua Tcl/Tk they
can install, but that doesn't work with a GRASS binary distribution
that was compiled for the UNIX model of TclTk. Many users will have
TclTk installed as part of some packaging system like fink, or could
add it to their installation relatively easily, but the idea here is
that relative newcomers to Unix software on the Mac platform might be
able to install a grass binary distribution with a minimum of
"overhead" requirements. We've handled GDAL by including a shared
library in $GISBASE/lib, Paul has mentioned that this could be done
with libproj too, now I'm wondering about Tcl/Tk.

I figured that the simplest way might be to compile it and then provide
a tarball of the installed files with instructions on how to expand it
on to the user's system, with a recommendation that it go under
/usr/local - this keeps things pretty simple.

I imagine this would work, but it got me thinking.... TclTk only uses
the bin, include, lib, and man directories for installation - if it was
expanded into the GISBASE directory, would that work? The idea would
be to ensure GRASS/tcltkgrass/NVIZ would work on the system with
minimum change to the rest of the user's system. And then we also make
sure that the version of tcl/tk matches what the nviz compilation is
expecting, and don't have to give instructions re: changing
LD_LIBRARY_PATH, etc...

Or is that like playing with a hornet's nest? I vaguely recall
discussion of problems with including tcl headers in the distribution,
but don't remember the context and don't really trust the memory.

It should work, although it may be necessary to explicitly set
TCL_LIBRARY and/or TK_LIBRARY.

But the same could be said of any other library. Do we include
everything which is listed in REQUIREMENTS.html? With more specialised
libraries such as GDAL and PROJ, there's a reasonable case for
bundling, as few systems will use these libraries for anything other
than GRASS (plus the fact that GDAL is likely to have even more
dependency issues than GRASS).

But Tcl/Tk is a fairly standard library, and is quite likely to be on
the system already. If we bundle that, where does it end? Are we going
to start bundling OpenGL or X11?

Personally, I don't think that we should be bundling anything for
which there is an existing version which could reasonably be
considered "standard". That probably includes zlib, curses, X, Tcl/Tk,
OpenGL, PNG, JPEG, TIFF, PostgreSQL and FreeType. It may or may not
include FFTW, BLAS/LAPACK, GDAL and PROJ.

--
Glynn Clements <glynn.clements@virgin.net>

3

I agree with your logic completely, it's just that on the Mac OS X platform, at least so far, Apple has seen fit to bundle MOST standard stuff along with its FreeBSD-based system, including everything else you mention (even LAPACK!), but for whatever reason, they do NOT bundle Tcl/Tk. So I went on a search for an easy-to-obtain alternative to point people towards, and all I can find are (1) package managers like fink that include it, or (2) the "native"/Aqua version of Tcl/Tk.

So for every other platform I've used, I agree that it is likely to be on the system already, but not for OS X.

So I'll play around with including it to see if it works, and either do that or set up instructions for installing my compiled version to go with the binary dist.

Thanks!
Scott

On Tuesday, Mar 2, 2004, at 21:29 Canada/Eastern, Glynn Clements wrote:

It should work, although it may be necessary to explicitly set
TCL_LIBRARY and/or TK_LIBRARY.

But the same could be said of any other library. Do we include
everything which is listed in REQUIREMENTS.html? With more specialised
libraries such as GDAL and PROJ, there's a reasonable case for
bundling, as few systems will use these libraries for anything other
than GRASS (plus the fact that GDAL is likely to have even more
dependency issues than GRASS).

But Tcl/Tk is a fairly standard library, and is quite likely to be on
the system already. If we bundle that, where does it end? Are we going
to start bundling OpenGL or X11?

Personally, I don't think that we should be bundling anything for
which there is an existing version which could reasonably be
considered "standard". That probably includes zlib, curses, X, Tcl/Tk,
OpenGL, PNG, JPEG, TIFF, PostgreSQL and FreeType. It may or may not
include FFTW, BLAS/LAPACK, GDAL and PROJ.

------
Scott W. Mitchell Scott_Mitchell@carleton.ca
Department of Geography and Environmental Studies
Carleton University, B349 Loeb Building
Ottawa, ON Canada
+1-613-520-2600 ext 2695

4

I agree with your logic completely, it's just that on the Mac OS X
platform, at least so far, Apple has seen fit to bundle MOST standard
stuff along with its FreeBSD-based system, including everything else
you mention (even LAPACK!), but for whatever reason, they do NOT
bundle Tcl/Tk. So I went on a search for an easy-to-obtain
alternative to point people towards, and all I can find are (1)
package managers like fink that include it, or (2) the "native"/Aqua
version of Tcl/Tk.

So for every other platform I've used, I agree that it is likely to be

on the system already, but not for OS X.

So I'll play around with including it to see if it works, and either
do that or set up instructions for installing my compiled version to
go with the binary dist.

I think it might be quite a bit less work (both near and long term) & a
more correct development path to just go ahead and fix tcltkgrass so the
user can use the Mac version of Tcl/Tk .. then the problem goes away.

NVIZ is another story of course, but getting the main GIS menus working
should take priority IMO.

How does OpenOSX get NVIZ to work if they use Apple's Tcl/Tk ??

Glynn already described the bulk of what needed to be done to tcltkgrass:
  http://article.gmane.org/gmane.comp.gis.grass.devel/2681

regards,
Hamish

5

Hamish wrote:

How does OpenOSX get NVIZ to work if they use Apple's Tcl/Tk ??

The OpenOSX changes were only to tcltkgrass, not NVIZ; NVIZ still
requires an X server.

Making NVIZ work with Apple's Tcl/Tk would also require making it work
with Apple's OpenGL (i.e. using wgl* instead of glX*).

--
Glynn Clements <glynn.clements@virgin.net>