beginnings of a gh_ interface for stk

From: Jim Blandy <jimb_at_cyclic.com>
Date: Tue, 29 Apr 1997 16:43:22 -0500

[Russ posted an implementation of the GH interface on top of STk to
the STk mailing list. He says:]
>i know this is a bit late, but i use the following quite
>effectively. maybe someone can clean it up a little bit
>and include it in stk.
>
>to use this code, #include <gh_extra.h> into your code,
>and link in gh_extra.o. then one can code with the gh_
>api in stk. mostly, anyway.

I think it would be very sad to have implementations of GH for many
Schemes, but have each one use a different header file. That makes a
given file of C code specific not just to GH, but to a specific
*implementation* of GH, which kind of defeats the purpose. Folks
should be able to write C code that is completely portable between GH
implementations.

A solution should permit people to have multiple implementations of GH
installed simultaneously --- i.e. both STk and Guile. I guess which
implementation you wanted would need to be specified by a command-line
#define or something.

Not that Guile's GH doesn't commit the same sin at the moment, mind
you. Just that it's a nasty trend to watch out for, and fix while GH
is young.

Perhaps all GH implementations on Unix could agree to install header
files like this in the standard #include path:

/* gh.h --- generic GH Scheme/C interface header file */

#include GH_BASE

Then, the build system for C code that uses GH could detect which GH
implementations are available, and choose one by #defining GH_BASE to
be <guile/gh-base.h> or <stk-gh-base.h>, or whatever.

Is there a clean way for the build system to say "use whatever's
installed, if there's more than one, pick one"?
Received on Tue Apr 29 1997 - 23:42:32 CEST