Compilation report, as promised

[Grass package]

GRASS USERS:

Following email by Darrell McCauley, who wanted to know why lots of
prospective grass users were installing binaries instead of compiling from
source code, I decided to take up the challenge and have a go at compiling
grass4.1.3 (main and alpha source only) for Solaris 2.3. I had no previous
experience with compilation. The following report may, I hope, tempt 
others into compiling grass for themselves...

1. You really need the installation guide to do this. It is available by
   anonymous FTP from the moon, directory grass/grass4.1/documents, file
   installGuide.ps.Z. First problem: you need to know how to unpack and
   print files like these. Use uncompress and a PostScript printer.
2. The installation guide assumes that you already have a tape with the
   Grass source code and sample data on it, and provides detailed instruc-
   tions to load these into your computer. It doesn't tell you that, and
   how, you can FTP grass source from the moon. My source came from tape,
   and was loaded by a systems manager, so I cannot comment on this part
   of the installation guide.
3. The compilation proper (section 7 of the installation guide) starts 
   with the running of the setup script. In order to be able to answer all
   its questions about your system, you must either know A LOT about it, 
   or enlist the help of a systems manager. Go through the sample header
   files provided in section 17.8 of the installation guide with him/her,
   and MAKE SURE that the variables set during setup are correct, ie do
   the paths and libraries really exist? Best thing would be to run the
   setup script in the presence of a systems manager. When the script has
   run, check the contents of the header file in the src/CMD/head direc-
   tory and discuss anything you don't understand with the systems
   manager before you continue with the next step.
4. Section 7.4 of the installation guide contains two slight errors. The
   command to determine the architecture name should read:
		gmake4.1 -sh | grep ARCH
   and the local.example file actually lists DIGITIZER drivers instead of
   display drivers.
5. Section 7.6 of the installation guide contains an error. In a Bourne 
   shell, output is captured with:
		sh GISGEN 2>&1 | tee /tmp/GISGEN.out
   ie there is NO space before the ampersand. Also, this section does not
   mention that re-running GISGEN, or resuming compilation by skipping a
   failed directory, will overwrite your GISGEN.out file unless you 
   specify a new name for it.
6. When compilation fails for a particular tool, you may decide to skip
   it because you don't think you'll ever need it. In such a case, you 
   should always note exactly what went wrong with the compilation at this
   point, because the same error may occur later on with a tool that you
   DO need.
7. Many useful programs are NOT in the main or alpha sections of Grass.
   Unfortunately, the installation guide is very brief about these, and
   basically tells you that you're on your own now and can only hope that
   installation guidance has been provided in some README. It's well
   worth trying to compile contributed, related, garden, or incoming
   software simply by FTPing it to its proper directory and running gmake4.1
   in it though. Nothing ventured, nothing gained.
8. Section 8 of the installation guide twice mentions the automatic creation
   of fifo pipes for graphics communication (page 14, note 12 and page 15,
   note 1). I'm not entirely sure this is correct - in any case GISGEN did
   not overwrite the existing fifos with new ones.
9. Section 9 of the installation guide could be a bit more explicit about
   the fact that you should copy the digcap.sample file to a new file
   called digcap (not digitcap as I did, analogous to the monitorcap file
   created in section 8), then uncomment the relevant lines.
10. I have not configured any digitizer or paint drivers, either locally or
   remote, so I can't comment on this part of the installation.
11. Loading the sample databases and moving existing grass data to their
   correct location in the new grass4.1 tree was no problem at all.
12. Cleaning up object files and source code as suggested in section 15 of
   the installation manual also posed no problem.
13. All in all, provided that you and you system manager took the trouble
   to find out about all the setup variables, the installation should not
   take more than about 2 hours. I did not do this, and spent 4 days
   just figuring out what all the error messages meant, and eventually got
   Darell McCauley and Jan Hartmann to help me out... Thanks again!
14. If I may make a suggestion to the people behind grassbug at zorro, it
   seems clear that the main hurdle for inexperienced users to compile
   grass is the setup script, which requires rather intimate knowledge of
   the operating system. Could the script be extended to help you find out
   about your own system, for instance by searching for EXTRALIBS that 
   might be used during the installation?
15. I append the header file that I ended up using. Perhaps others compi-
   ling grass for Solaris 2.3 can use it:

CC                  = gcc
ARCH                =

GISBASE             = /home2/anh/grass/grass4.1
UNIX_BIN            = /users/anh/grass/bin

DEFAULT_DATABASE    = /users/anh/grass/data
DEFAULT_LOCATION    = caa92

COMPILE_FLAGS       = -O
LDFLAGS             = -s

XCFLAGS             = -D_NO_PROTO
XLDFLAGS            =
XINCPATH            = -I/opt/X11/include
XMINCPATH           =
XLIBPATH            = -L/opt/X11/lib
XTLIBPATH           = -L/opt/X11/lib
XMLIBPATH           = 
XLIB                = -lX11
XTLIB               = -lXt
XMLIB               =
XEXTRALIBS          = -lsocket -lnsl

TERMLIB             = -ltermlib
CURSES              = -lcurses $(TERMLIB)
MATHLIB             = -lm

LIBRULE             = ar ruv $@ $?

USE_TERMIO          = -DUSE_TERMIO
USE_MTIO            = -DUSE_MTIO
USE_FTIME           =
DIGITFLAGS          =
VECTLIBFLAGS        =
GETHOSTNAME         = -DGETHOSTNAME_UNAME
 
*******
Martijn van Leusen
Birmingham University Field Archaeology Unit
*******