[GRASSLIST:4248] Re: compiling Grass5pre5 on Cygwin

[Thomas Dewez]

Glynn and everyone,

By the way, what is the difference between a header file (which is what the
include is all about, right?) and the library proper. What sort of file
should the include and library folder contain?

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

Is it the same thing to do
--with-<package>=no
and
--without-<package>

In english, it sounds very much the same but it may not be the same in
"computer" language.

> 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.

Is there a way to be systematic about checking the default paths? Are they
listed somewhere? Would this be a good idea to have such look-up file setup
so that the ./configure command does not span 10 lines and take ages to
adjust? I say this innocently, not knowing how effort is necessary.

Finally, I seem to be turning a lot of options off where the compiler cannot
find them. Recently, Markus (I think) mentioned where fftw was used. Would
it be a good idea (unless it exists already somewhere) to have systematic a
list of modules that use such and such libraries so the user can decide
whether it is clever to turn them on or off?

Cheers,

Thomas

----- Original Message -----
From: "Glynn Clements" <glynn.clements at virgin.net>
To: "Thomas Dewez" <thomas.dewez at brunel.ac.uk>
Cc: "Markus Neteler" <neteler at itc.it>; "GRASSLIST" <GRASSLIST at baylor.edu>
Sent: Thursday, August 08, 2002 12:31 AM
Subject: Re: [GRASSLIST:4239] Re: compiling Grass5pre5 on Linux


>
> 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>
>