From octave-maintainers-request at bevo dot che dot wisc dot edu Sun Jan 25 22:26:41 2004
Subject: Re: DLD compilation errors
From: Paul Kienzle <pkienzle at users dot sourceforge dot net>
To: octave-maintainers at bevo dot che dot wisc dot edu
Cc: gdg at zplane dot com
Date: Sun, 25 Jan 2004 23:25:29 -0500


On Jan 23, 2004, at 7:59 PM, John W. Eaton wrote:

> First, we should separate the parts of Octave's config.h file that are
> specific to Octave and might be needed by users writing .oct files and
> put them in a separate file (not called config.h).  This new file
> would be installed and users could include it if needed (oct.h would
> include it).  All the rest of the configuration information needed to
> build Octave could go in config.h, which need not be installed.  If
> users writing .oct files need similar system-specific information,
> they would need to have their own configure scripts.
>
> Second, it would be great if we could eliminate the need for
>
>   TWO_BYTE_INT
>   FOUR_BYTE_INT
>   EIGHT_BYTE_INT
>
> in liboctave/data-conv.h and
>
>   SIZEOF_INT
>   SIZEOF_LONG
>   SIZEOF_LONG_LONG
>   SIZEOF_SHORT
>
> in config.h.  I think it would be best to have this information
> decided at run time (that would help with cross-compiling).
>
> Third, oct.h needs updating to include all the relevant headers.  Or,
> better yet, we need to finally decide on what interface to make public
> and export to users and what should be private, and only put the
> public interface in oct.h (and maybe it should be renamed octave.h).
>
> Comments?

A standard API with fixed headers is pretty powerful, especially if
it means you can compile an extension for one version of octave
and run it against another version.  Tcl provides this with their
stubs interface, which means that my extension can work with
any version of Tcl created in the last four years (I don't use many
new and exotic features).  That means the API cannot directly
expose Octave's classes, otherwise even minor modifications
would not be possible (add a new data field or function to the
superclass and C++ will no longer know where to find its data).

One thing Tcl has discovered is that some extensions insist
on using the Tcl internals.  Of course, these are bound to
specific Tcl versions but the package authors acknowledge
that, and eventually the facilities are added into the mainline
to support the things that used to require private headers.

Paul Kienzle
pkienzle at users dot sf dot net