[GRASS-user] Compiling grass 6.2.1: i.class error

[Glynn Clements]

Sean Fulton wrote:

> > [Although curses is technically an optional dependency, a lot of GRASS
> > components require it, and many of them don't explicitly check for its
> > presence; they just assume it is available and fail (with an error) if
> > it isn't.]
> 
> I'll look into that. I know I did try to compile it --without-curses 
> and sputtered and choked.

If you have a partial build, you need to run "make distclean" before
re-running configure with different switches. GRASS doesn't have
complete dependency information (the sheer number of subdirectories
makes this impractical), so if the configuration options are changed,
some things which need to be re-built won't be.

> Is that switch useful for some reason? Compiling libgrass?

It's potentially useful if you only need a partial build (e.g. for a
web application), and are willing to deal with any problems (e.g. 
lib/init is going to fail on set_data etc, so you will need "make -k"
to get it to build other stuff in that directory). In that situation,
you need to be able to force configure not to fail because of the lack
of curses.

Every other --without-* switch should work without requiring
additional effort from the user, but curses is currently sufficiently
ingrained that making --without-curses work nicely is too much effort
for a relatively obscure usage case.

> The build system doesn't seem to be very smart about finding libs and 
> includes so I might have missed a necessary configure option somewhere. 

It doesn't try to be smart; it tries to do what it's told. E.g. it
will only add additional -I and/or -L switches in response to a
corresponding --with-*-includes= or --with-*-libs= switch.

At one time it tried being smart; frequently, it would pick up things
which it shouldn't have (particularly on commercial Unices with both
vendor and GNU versions of various packages which didn't like being
mixed) resulting in complete failure to build anything (telling gcc to
use the vendor's libc headers instead of its own tends to do that).

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