[GRASS5] optional bundled libraries

Glynn Clements glynn.clements at virgin.net
Wed Mar 3 14:55:14 EST 2004


Michael Barton wrote:

> > 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.
> 
> Your point is well taken. However, of the many libraries you mention 
> below, how many are needed for running GRASS binaries and how many are 
> needed for compiling it?

All of them (except BLAS/LAPACK) are used by something. If any of them
are dynamic libraries, those need to be present in order to run the
corresponding modules. Static libraries and header files are only
needed for compiling.

> To simply run GRASS (i.e., the XWindows version) on my MacOSX system, I 
> *think* that I only need
> 
> XWindows
> TclTk
> GDAL (actually only libgdal for importing)
> PROJ

AFAICT, those are the ones which are least likely to be installed by
default. GDAL and PROJ are unlikely to be used by anyone who isn't
involved with GIS. X is a complete "subsystem" rather than a mere
library. Tcl/Tk is installed by default, but it's the Mac version
(which is probably sufficient for most purposes, but not NVIZ).

FWIW, you definitely need zlib (required by libgis; nothing will work
without this), and curses is used for the text startup screen and many
of the interactive modules. But those libraries are very standard, and
will almost certainly be installed already.

The others are only used by specific modules (e.g. PNG is only used by
r.in.png, r.out.png and the PNG driver), so you only need those if you
need to use the corresponding modules.

> Perhaps I am misled about this, but this seems to be a minimum that I 
> need to install. Perhaps all the rest are needed but ARE part of modern 
> standard OS package installation (or at least standard X11 
> installations). I will admit that I am not clear on this. The problem 
> that prompted my query to Scott and Scott's to the list is that X11 is 
> widely available in binary form for all the systems that GRASS runs on; 
> the other 3 are not.
> 
> The versions of GDAL and Proj available from the major Mac packaging 
> service (fink) are (or at least very recently were) out of date and/or 
> incomplete both as binaries and as source packages, meaning that anyone 
> wanting to use these must compile them from scratch. They are not 
> available as standard CYGWIN install packages either.
> 
> TclTk is equally problematic. It IS available to compile from the fink 
> packaging service for Mac, but not as binary anywhere that I can find 
> (I thought I found a source, but it was missing Wish). This means that 
> to simply get TclTk, you have to install fink also or compile from 
> scratch. I like fink, but it would be nice if Mac users did not HAVE to 
> use it. It is worse for CYGWIN. The CYGWIN version of TclTk is 
> incompatible with GRASS and a compatible binary is provided on the 
> WinGRASS site.
> 
> Ironically, PostgreSQL, which is useful but not necessary for simply 
> running GRASS, is widely available in binary form for all major systems.
> 
> Ideally, what I'd like to see is a way to have access to the minimum 
> requirements to run GRASS available from the main GRASS site and 
> mirrors--either as packages for downloads or links to reliable sites 
> for the resources in binary form. Perhaps this is unrealistic. Perhaps 
> the move toward shared libraries will eventually solve this.  I'd like 
> to see GRASS more widely used. I've found it to be a highly useful GIS 
> and image analysis package, and the direction it is now being taken 
> could make it equal to the best on the market. However, IMHO most 
> people who use GIS won't use GRASS if they have to compile it or any of 
> its required resources.

Don't get me wrong, I accept that it ought to be possible to install
and use GRASS without having to compile *anything*. I'm just saying
that (except for GRASS itself) we should only provide binaries if
we're sure that nobody else does.

If binaries are available, we should provide links rather than
bundling the binaries.

If binaries are available but, for whatever reason, aren't suitable,
the first step should be to see if whoever produced those binaries is
willing to deal with the issues (e.g. provide an updated version).

And the second step should be to check whether we can reasonably make
GRASS work with commonly installed versions (i.e. ensure that we
aren't insisting on a recent version simply because that's what the
devloper had on their system).

E.g. with tcltkgrass, it would be much better to change tcltkgrass to
work with the native MacOSX/Aqua Tcl/Tk. OpenOSX have already done
some work in this area, but I haven't noticed any effort being made to
integrate that into the official GRASS sources.

OTOH, that probably isn't an option for NVIZ, as it would require
making Togl to work with the native versions of both Tcl/Tk and OpenGL
(and, unfortunately, NVIZ' portability has been getting worse rather
than better lately).

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




More information about the grass-dev mailing list