[GRASS5] Solaris9 test of 5.4

[Glynn Clements]

Gordon Keith wrote:

> > > It would be nice if grass was also a simple configure; make; make
> > > install. If configure would look for postgress in /usr/local/pgsql and
> > > include /usr/ sfw/{include,lib} on solaris it would be good.
> >
> > The configure script used to autodetect directories; we took that
> > feature out because it tended to find things which broke the build,
> > making it impossible for some users to build GRASS.
> 
> OK, sounds reasonable.
> 
> I still think ./configure; make; make install should work inmost cases, at 
> least for a stable release (5.4).
> 
> Currently there seems to be two problems:
> 1) you need to create and use a separate build directory

That's quite common for large projects; e.g. both gcc and glibc now
require this (or, at least, state that building within the source tree
is "unsupported").

The advantages include:

1. Eliminating the need for a recursive "make distclean" mechanism
(you can just "rm -rf ..." the build directory).

2. Eliminating the need to run "make distclean" before "cvs update".

3. Being able to keep multiple builds on the same system, e.g. keeping
both debug and optimised (or with and without postgres) builds lying
around.

4. Being able to build for multiple systems from a single source tree
(which can be shared via NFS or similar).

5. You don't need write permission on the source tree in order to
build it (which is useful if it's a read-only NFS export, or you want
to build someone else's tree on a multi-user system).

> 2) postgres puts it's bits in /usr/local/pgsql instead of /usr/local

More precisely, the headers normally go into a separate subdirectory
(not necessarily "pgsql"; IIRC, Cygwin uses "postgres"), but the
headers aren't designed to be used that way.

For comparison, X11 headers go into a subdirectory, but the
subdirectory forms part of the name by which the headers include each
other, e.g. "#include <X11/Xlib.h>". Same with OpenGL, GTK+ etc.

Also, headers are often put into a subdirectory to *prevent* them from
being picked up automatically (e.g. GTK+ 2.x "hides" its headers in a
subdirectory so that GTK+ 1.x programs don't use them accidentally).

> I know nothing about how to fix 1 but would it be possible to create a default 
> build directory and use it unless a switch is provided (eg --build-dir=)
> 
> With 2 it would be good if either the default build was --without-postgres or 
> configure looked for postgres files under /usr/local/pgsql.

If --without-postgres was the default, we'd be forever dealing with
queries of the form "the postgres-related modules don't work".

Forcing users to supply switches was a deliberate decision, on the
grounds that users seem to find it hard to overlook the fact that they
had to discover and then supply a switch whereas they found it very
easy to overlook a "WARNING: PostgreSQL support disabled" message.

BTW, /usr/local/pgsql isn't the right place in most cases. While GDAL,
PROJ and (to a lesser extent) FFTW are fairly obscure, and may have to
be installed from source or a third party package, most Linux vendors
provide an official PostgreSQL package (RPM/.deb/etc) which installs
under /usr.

> I suspect the 
> former may be cleaner. If you have to specify postgress include and lib 
> switches then having to provide --with-postgress makes sense.
> 
> Just my $0.02 as someone who only installs grass occassionaly and would really 
> like to be able to just install it without having to figure out all the 
> configure switches first.

Given that most users will probably have to locate and install (and
quite possibly compile) at least one of PROJ, GDAL and/or FFTW (the
rest are often already installed), expecting them to supply a couple
of switches isn't considered a big deal. It also has the advantage of
coercing them into reading the "configure --help" text.

In short, the need to supply a few switches in typical cases has as
much to do with psychology as with technical issues.

Also, it helps acclimate them to the fact that, once GRASS has finally
been compiled and installed, typing "grass" doesn't present them with
an intuitive GUI program which can be used productively without
reading a word of documentation. It's not that kind of package.

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