[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
liboctave standalone
From: |
John W. Eaton |
Subject: |
liboctave standalone |
Date: |
Fri, 14 Feb 2003 13:33:56 -0600 |
On 14-Feb-2003, Marcin Baranowski <address@hidden> wrote:
| It is possible to use liboctave as standalone library to link with C++
| applications. It has nice C++ classes interface.
| Unfortunately, it requires some libraries, that absolutery aren't needed by
| non-interactive applications (or applications with graphical frontends).
|
| It's possible to move some symbols from liboctave to octave binary, for
example.
| These are: pic/cmd-edit.o pic/cmd-hist.o pic/oct-rl-edit.o pic/oct-rl-hist.o
| (both requires libreadline and libncurses).
I would prefer to split liboctave into several pieces instead of
moving these to the Octave binary.
| Also, little change in
| liboctave/str-vec.cc:
| int line_length = command_editor::terminal_cols ();
| to
| int line_length = 80;
I think it would be better to use something like
typedef int (*FP) (void);
extern FP lo_terminal_cols_fcn;
...
line_length = lo_terminal_cols_fcn ? lo_terminal_cols_fcn : 80;
and have lo_terminal_cols_fcn be initialized to
command_editor::terminal_cols if we link with the library that
contains the command_editor class. Otherwise, it defaults to 0.
There may be other problems with the kpathsearch library, if we ever
reach a point where that can be removed from Octave.
I don't have time to work on a patch for this now, but if someone can
actually make it work, then I would consider it. I tried once, but
ran into various problems, I think with some circular dependencies
between liboctinterp and liboctave.
jwe