This is the mail archive of the guile@cygnus.com mailing list for the guile project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
> 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