[GRASS5] most recent snapshot

[Glynn Clements]

Roger Miller wrote:

> I had three packages that did not compile.  NVIZ2.2 didn't compile.  The 
> reasons were rather complicated but all seemed related to the make system 
> rather than to the code itself.

Can you provide error messages? Building NVIZ is complicated by
depending upon OpenGL and Tcl/Tk, both of which have variations
depending upon platform and version.

> s.surf.rst did not compile because it 
> couldn't find "glocale.h.".  That file doesn'.t exist anywhere in the 
> snapshot (or in the pre2 release)  so it appears to be a problem with the 
> code.

Can you tell whether the snapshot is based upon the (now defunct)
release branch, or the head? If there are any "CVS/Tag" files, it's
the release branch.

glocale.h was committed to the head at the end of February. IIRC, this
is used by the grass.postgresql programs (which were committed to the
head), and s.surf.rst (which was inadvertently committed to the
release branch).

FWIW, glocale.h is just:

	#include <config.h>
	
	#ifdef HAVE_LIBINTL_H
	#include <libintl.h>
	#define _(str) gettext(str)
	#else
	#define _(str) str
	#endif

> r.mapcalc also didn't compile.  The problem appears to be that some 
> files that should have been previously deleted (lex.yy.c and y.tab.c, maybe 
> others) were not.  This could be a make problem, but it also may have been 
> caused by my procedure.

I made some changes in that area. Basically, I changed the invocation
of lex and yacc so that they use the default filenames (lex.yy.c,
y.tab.[ch]). These are the files which the "maintainer-clean" target
now removes. If the snapshot was installed over an existing directory,
or if "make maintainer-clean" wasn't run prior to creating the
snapshot, that might cause problems.

> The whole procedure probably took 4 hours.  Some of that time was spent 
> making sure my resource manager worked.  Tracking down the problems with the 
> three modules that didn't compile took some time as well.

Once configure has succeeded, anything which fails to compile should
be reported to this list. Even if you can determine a solution or
workaround yourself, it would be useful for us to know of any
potential problems.

s.surf.rst is almost certainly due to a "bad" snapshot. r.mapcalc
might be. NVIZ could be, or it could just be a particular permutation
of platform/version issues which hasn't been allowed for.

> It took a 
> disappointingly large amount of time to figure out which options I had to 
> specify to get everything to compile.  In particular, I found that I had to 
> specify the location of the postgres includes even though (as I recall) they 
> are installed to the default location for postgres 
> ("/usr/local/pgsql/include").

Configure doesn't attempt to guess include/library directories, so the
only includes/libraries which will be found are those which are in the
compiler's/linker's default paths. IOW, -I or -L switches (apart from
those which refer to directories within the GRASS source tree) will
only be added if a corresponding --with-*-includes or --with-*-libs
switch is given to configure.

Because of the large number of external dependencies, there had been
problems with configure adding directories which contained conflicting
files. Not only did this result in build failures but, in such cases,
there wasn't any way to fix the problem without manually editing the
"head" file.

Also, most of the dependencies are required by default; either you
have the corresponding package, or you use the --without-* switch, or
you get a fatal error. This behaviour was chosen as a result of users
not noticing warnings from configure, then reporting the resulting
build failures to the list.

Of the "standard" dependencies (DBM, JPEG, TIFF, PNG, GD, Tcl/Tk,
PostgreSQL, OpenGL, UnixODBC, FFTW), the only switches which are
normally required are --with-postgres-includes (usually required), and
--with-dbm-includes (less often required). All of the other packages
tend to either:

a) have their headers in a standard include directory (/usr/include or
/usr/local/include), or

b) have their headers in a subdirectory of a standard include
directory, and include the subdirectory in any references to their
headers (e.g. OpenGL uses "#include <GL/gl.h>").

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