[GRASSLIST:4245] Re: compiling Grass5pre5 on Linux

[Glynn Clements]

Thomas Dewez wrote:

> Could somebody state how things should be written down for customizing the
> configure script? I mean, if I want to include a package whose assumed path
> is not correct what do I do?

Use the appropriate --with-<package>-includes and/or
--with-<package>-libs switches.

Note that the "assumed" paths are those which are assumed by the
compiler (for includes) and linker (for libraries). The exact paths
depend upon the compiler or linker; however, includes which are in
/usr/include and libraries which are in /lib or /usr/lib should be
found automatically. Files which are in any other directories won't
normally be found without the addition of the appropriate switch.

The situation for include files which are in subdirectories of
/usr/include is more complex. E.g. the OpenGL headers are normally in
a subdirectory called "GL"; *however*, the subdirectory is part of the
name which is used in the source code, i.e.

	#include <GL/gl.h>

So, if the file is /usr/include/GL/gl.h, it will be found without any
switches. OTOH, The PostgreSQL headers are often in
/usr/include/pgsql, but the subdirectory isn't part of the name, i.e.

	#include <libpq-fe.h>

Consequently, you have to add the directory to the compiler's search
path, with

	./configure --with-postgres-includes=/usr/include/pgsql

Sometimes, a package's headers are split across multiple directories.
In this case, you have to supply a list of directories separated by
spaces (which requires the use of quotes), e.g.

	./configure --with-postgres-includes='/usr/include/pgsql /usr/include/pgsql/internal'

> There's the include thingy and the lib thingy that need be
> specified, but in what order?

The order shouldn't matter. For a given package, it definitely doesn't
matter which order you use for --with-<package>-includes and
--with-<package>-libs.

It is possible for the ordering of multiple -includes switches or
multiple -libs switches to matter but, fortunately, this is uncommon
on "normal" systems. It's most likely to happen on systems where
multiple versions of a particular package are installed; e.g. at one
point, I had three different versions of the GLU library, in /usr,
/usr/local, and /usr/X11R6.

> Not sure what the include and lib must contain to work.

Each --with-<package>-includes switch adds one or more -I switches to
the compiler flags which are used when compiling any module which uses
that package. similarly, each --with-<package>-libs switch adds one or
more -L switches to the linker flags which are used when linking any
module which uses that package.

However, I suspect that explanation doesn't help much ;)

As a rough guide, if a particular include file isn't found, first try
adding the "include" directory beneath which the file resides. E.g. if
the file is at /usr/local/include/foo/foo.h, try using
--with-foo-includes=/usr/local/include. If that doesn't work, add
another component, i.e. --with-foo-includes=/usr/local/include/foo.

In some cases, you can't figure out the necessary option without
understanding what other packages are required. E.g. the Tk part of
Tcl/Tk requires X; if the X headers aren't found, the tk.h check will
fail regardless of any --with-tcltk-includes option.

Sometimes the config.log file will provide useful clues. It may help
to include the relevant portion of this file when requesting help in
dealing with a specific configure problem.

> I know it is basic but would appreciate a quick explanation.

Actually, it's far from basic, and I'm not sure that there is any
"quick" explanation; at least, not one which doesn't assume a
reasonable degree of familiarity with compiling and linking.

The main reason why configuring GRASS is so complex is because it can
use so many external libraries (see REQUIREMENTS.html). If it only
used a few, the configure script could be made more "intelligent",
i.e. it could attempt to guess which directories were required without
having to be told.

But this just doesn't work when you are dealing with around 20
different libraries, some of which are interdependent. Sometimes it
will guess wrong, with the result that even a relatively experienced
developer could spend days trying to figure out how to get it to
build.

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