[GRASSLIST:5340] Re: Would a simpler, common, configuration be desirable?

[Glynn Clements]

[Similar questions arise on both this list and the developers' list
occasionally, so I'll provide a fairly thorough (i.e. long) answer in
the hope that I can just paste bits of it in reply to any future
occurrences.]

[Disclaimer: I tend to be more conservative regarding configure issues
than I would expect of the other developers. That's probably because
I'm most likely to be the person who ends up dealing with anything
that goes wrong. However, I'm not the final arbiter of such decisions,
and other developers may be more readily persuaded of the overall
desirability of any proposed changes.]

William L. Baker wrote:

> I notice that a lot of discussion goes into how to get configuration to
> work under various Linux distributions. It seems there are two issues:
> 1. files may be in different places, 2. necessary libraries, include
> files must be downloaded and installed as they are not part of standard
> Linux distributions or else not part of their default installations.
> 
> I've been installing under Mandrake for a while, and I always have to
> add a bunch of --without-fftw sorts of things to ./configure statement
> as I just need the basic core of GRASS.
> 
> Would it be better to start with a common core of GRASS that can
> probably
> be configured under most distributions without additions to ./configure,
> so that most people could just download GRASS source, type ./configure,
> make, make install and have a functioning program?
> 
> Maybe a separate "./configure_extras" or something could do all the
> stuff that seems to be lacking from many distributions or requires that
> we point to where the files are? (e.g., fftw, postgres etc.)
> 
> Maybe someone has thought about this already and decided it's not a good
> idea or just not possible?

There are two issues here:

1. Prior to this revision:

	revision 1.64.2.31
	date: 2001/09/19 19:41:27;  author: glynn;  state: Exp;  lines: +364 -102
	Allow optional dependencies to be disabled
	Make all include/library detection failures fatal

the configure script would just print a warning then carry on if an
optional dependency wasn't found. However, a significant number of
users seemed to overlook the warning, then report as a bug the fact
that the corresponding modules didn't compile.

Consequently, it was decided that the absence of any of the common
optional dependencies would result in a fatal error. The rationale
being that users would presumably find it harder to overlook having
explicitly used e.g. --without-postgres than to overlook a warning
message.

2. Prior to this revision:

	revision 1.64.2.13
	date: 2001/07/28 05:33:05;  author: glynn;  state: Exp;  lines: +592 -773
	Simplified configure script.
	
	Doesn't go wandering around the filesystem looking for headers and
	libraries; if they're not in standard locations, you have to tell it.

	[snipped]

the configure script would automatically look in about half a dozen
"common" directories for headers and libraries. This probably worked
fine for the people who added their systems' preferred locations to
the list, but for others the result was that configure would
automatically detect the wrong version of a particular header or
library, and everything else would fail from there on.

The end result was that it would then take a week of discussion
between the user and the developers to figure out exactly what the
problem was and exactly what configure had to be prevented from doing.

This isn't an issue on a typical "clean" Linux distribution, where
there is only one version of anything. On commercial Unices, where you
may have multiple versions of the vendor's libraries (e.g. 32/64 bit
versions, old-API/new-API versions etc), plus the GNU equivalents
(possibly both the vendor's "official" version of the GNU stuff and a
self-compiled version without the vendor's dubious "fixes"), it caused
actual problems.

The current behaviour is that configure doesn't add any -I/-L switches
to the compile/link commands of its own accord. Each use of
--with-*-includes/--with-*-libs will add a -I/-L switch for the
appropriate tests (i.e. --with-postgres-includes will add a -I switch
for the PostgreSQL header tests). --with-includes/--with-libs adds the
corresponding switch to the "base" flags which are used for all tests.

Basically, this means that most users will have to use at least a few
of these switches (primarily for PostgreSQL, because the PostgreSQL
developers pretend that their headers will go straight into
/usr/include, but the OS vendors invariably decide otherwise).

The plus side is that no-one ends up trying to figure out how to get
configure *not* to automatically add a -I/-L switch that ends up
breaking everything.

> If not this, then perhaps ./configure could end with an informative
> error
> statement, such as "necessary fftw libraries were not found on your
> system. Go to www.xxxx.xxx to get the necessary files or retype
> ./configure --without-fftw"?

We shouldn't really need to embed specific error messages for specific
libraries; any failure relating to an optional dependency could use a
generic "Please see the file REQUIREMENTS.html" message. However,
failures often occur when the package itself is actually installed; in
that situation, an overly "helpful" error message often comes across
as rather patronising.

> Just thinking of ways to make configure friendlier.  As Linux gains
> ground, GRASS is going to be used by more people who are frustrated by
> these little hurdles.

In general, the more dependencies a program has, the harder it becomes
to get "configure; make; make install" to just work in all cases. For
a package with a few dependencies, the total number of permutations is
low enough that you can account for all of the possibilities. As the
number of dependencies grows, the number of permutations goes through
the roof, and the only solution that doesn't cause insurmountable
problems for a substantial number of users is for configure to do
exactly what it's told to, and no more.

That isn't to say that the configure script couldn't be improved. 
However, not completely screwing people with "obscure" systems (i.e. 
anything other than this year's version of RedHat/SuSE/Debian) is
currently a higher priority than saving the average user from the
arduous task of reading INSTALL, REQUIREMENTS.html, and the output
from "configure --help" ;)

BTW, for the specific case of PostgreSQL, I'd much prefer it if users
just kept complaining to the PostgreSQL developers until they did
something sensible regarding the header locations. Any library which
has dozens of headers should really be using a prefix (in the sense
that OpenGL headers are called <GL/gl.h>, X11 headers are called
<X11/Xlib.h>, <X11/Xaw/Label.h> etc); yet PostgreSQL expects
libpq-fe.h et al to be directly in the compiler's include path.

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