Re: Announce: guile-dblib-0.9 available (beta software)

[Ian Grant <I.A.N.Grant@damtp.cam.ac.uk>]

> For starters, the configure script should guess the most common places
> that the Sybase files are installed.  It should just check for the
> presence of some distinctive header in a list of common directories.
> 
> Then, you should use a --with-sybase=PATH option; those are
> designed specifically for cases like this.  Look in the autoconf
> documentation for AC_ARG_WITH (look in the index under ARG_WITH).

This is what I did for the postgres module, but I felt slightly guilty,
because according to the coding standards --with-PKG is supposed to be
only used to configure optional packages for inclusion in the build.  But
there is no other mechanism to direct configure to the right places for
mandatory packages and furthermore everyone else is using with for this
purpose, so it's a de-facto coding standard if not de-jure.

I have written an m4 macro called GUILE_MODULE which is like GUILE_FLAGS
in guile.m4, except in that it caches the results of the guile-config runs
and reports each one as it does them. This makes it appear to be a lot
faster: those three invocations of guile take a while.

It also fetches (and caches) the datadir and libdir paths from
guile-config so that modules automatically install their .scm and .so
files in the right places. This cleverness only happens if --prefix is not
specified.

I had to make a decision about mixing .so and .scm files though. On our
site we have 8 architectures and guile is installed in /opt/GNU.
Subdirectories of /opt/GNU are switched using amd according to the
machine architecture. There is one single /opt/GNU/share directory though.
Now all the .scm modules should be installed under /opt/GNU/share, but the
.so libraries must be installed under the appropriate
architecture-switched /opt/GNU/lib directory. Unfortunately the module
system, so far as I can tell, will only load libxxx.so from the same place
as it would load xxx.scm  So to get around this I make a symlink
DATADIR/database/interface which points to
LIBDIR/guile-modules/database/interface which is where the libxxx.so file
really lives. 

For example, if --prefix were never used, guile would be in
/usr/local/bin, and libguile would be in /usr/local/lib. If someone then
built the postgres interface guile-pg, it would automatically install
its libpostgres.so in /usr/local/lib/guile-modules/database/interface and
it would install it's postgres.scm file in
/usr/local/share/guile/database. In addition it would make a symlink
called /usr/local/share/guile/database/interface which would point to
/usr/local/lib/guile-modules/database/interface.

Then (use-modules (database postgres)) will get the higher-level .scm
module in. Or the lower-level interface can be accessed with (use-module
(database interface postgres)) 

This could be used by all the database modules and unless someone has a
better idea I'd like to propose that optional separately packaged guile
modules follow this scheme.

PS The postgres module is progressing. I'm busy writing tests. But there's
a horrible stack-overwriting bug in the large object ports code that I
just can't find. I've spent at least 10 hours on it so far. In the process
I found lots of other bugs, but there's still this big nasty one ... :-(

Ian