octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: DLD compilation errors


From: Paul Kienzle
Subject: Re: DLD compilation errors
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
address@hidden



reply via email to

[Prev in Thread] Current Thread [Next in Thread]