Re: Renaming libcruft

[John W. Eaton]

On 24-Aug-2012, Rik wrote:

| I think that would be okay.  One question is whether there would ever be a
| point where we wouldn't want to link in the code that is represented by
| libcruft.  For example, would people ever make static .oct files that
| didn't depend on '-lcruft -loctave -linterp' and instead just had '-loctave
| -linterp'?  Maybe static .oct files are an impossibility given the
| DEFUN_DLD header.  Does anyone ever write their own C/C++ programs that
| only link against liboctave and not against either libcruft or
| liboctinterp?  If all of this sounds like an impossibility and libcruft is
| always required to be linked in with liboctave anyways then, yes, let's
| move the code of libcruft into liboctave.

Since liboctave depends on libcruft, you can't use liboctave without
libcruft.  Similarly, you can't use liboctinterp without liboctave and
libcruft.

So I think the question you are trying to ask is whether people write
programs in which they use libcruft by itself.  I'm betting the answer
is no.  Anyone who wants that functionality probably gets it by using
the code from netlib.  Most of what we have in libcruft is just
imported from netlib without much change.  So I don't see that it
would be common to use libcruft by itself, or that it would be a big
problem for anyone who does to start using the code separately from
Octave.

And anyway, the purpose of these libraries has always been to enable
the implementation of the Octave interpreter.  My attitude has always
been that if they work for other purposes, then that's great, but they
were never intended as general purpose numerical libraries.

| I would keep the code together since it is a very distinct entity and makes
| a natural convenience sub-library for liboctave.

What about subdividing the other parts of liboctave, similar to what
we did for what was in src (now libinterp)?

| The fact that it is
| Fortran really segregates it in my mind from the rest of the C++ sources. 
| I would still change the directory name away from libcruft to libfortran.

Not all the code in libcruft is Fortran.  Look at the misc directory.
That's mostly for interfacing C with Fortran, but it also has the
lowest-level error handling functions and variables.

jwe