Re: Binary compatibility issues with Hugs FFI

[Antti-Juhani Kaijanaho]

On Thu, Aug 26, 1999 at 06:10:13AM -0600, Alastair Reid wrote:
> It's documented in a C header file :-)

Ouch.

> Why is the FFI different from any other part of Hugs?

It might well not be.  I just ran into that particular problem when
working on Green Card.

> Or, to put it another way,
> shouldn't we be talking about version control for arbitrary Haskell
> files which include but are not limited to FFI-related files.

Possibly.  Actually, yes, we need to decide something about that, too.

The big question: 

 + Where should a Hugs extension module (either Haskell source alone
   or together with a shared binary object) go on the file system if
   installed as part of the OS?  What if it is installed locally by
   the administator?

And a related problem:

 + The Filesystem Hierarchy Standard (which I must follow because of
   Debian policy) specifies that architecture-independent files should
   be installed under /usr/share, whereas architecture-dependent files
   should not be.  Every Green Card module consists of both a Haskell
   source file and a shared binary object.  If one follows the FHS, one
   should install the Haskell source file in /usr/share/blah and the
   shared object in /usr/lib/blah.  However, if I have understood things
   right, Hugs looks for the shared object in the directory where the
   corresponding .hs file is.  How to solve this?  Invoke the Mad Symlinker?

It is my hope that we reach a solution to these problems on this list
and all (binary) redistributors of Hugs for Unices agree to implement it.

> GreenCard 2 used version 2.  This removed direct access to data
> constructors and added better support for types like pointers, foreign
> objects, etc.

So the current Hugs supports both version 1 and version 2 of the FFI?

-- 
%%% Antti-Juhani Kaijanaho % [EMAIL PROTECTED] % http://www.iki.fi/gaia/ %%%

   "... memory leaks are quite acceptable in many applications ..."
    (Bjarne Stroustrup, The Design and Evolution of C++, page 220)