Renaming libcruft

[John W. Eaton]

On 24-Aug-2012, Rik wrote:

| While you were away there was some discussion about renaming libcruft.
| 
| Pros:
| 
| 1) libcruft doesn't really convey anything and meaningful variable/library
| names help in understanding the source code.  For example, liboctinterp and
| liboctgui are both clear on what is inside them.

I disagree; libcruft is full of cruft!  :-)

| 2) It is nice for package maintainers (RedHat, Debian, etc.) if all of the
| libraries are in the same "namespace".  For example, on Debian libcruft is
| installed right alongside system libraries and it is difficult to
| distinguish what it is.  The other Octave libraries are in the "liboct*"
| namespace and this library should be as well.
| 
| Cons:
| 
| 1) Laziness.  The build system works and we would have to go through and
| find all mentions of libcruft and correct them.  But I'm willing to do the
| renamings if we go forward with this project.
| 
| Possible Names:
| 
| The difficulty is that there isn't much commonality in the code underneath
| libcruft so finding a meaningful library name is harder than it is for
| liboctgui.  Underneath libcruft we find some Bessel function code, an FFT
| implementation, numerical integration, ODE solver, etc.  Basically, the
| only commonality I see is that the routines were written in Fortran and
| written a long time ago.  Possible names that Mike Miller and myself have
| proposed are
| 
| liboctclutter
| liboctf77
| liboctfort
| liboctfortmath
| liboctfortran
| liboctinternal
| liboctlowlevel
| liboctmisc
| liboctugly
| 
| If I had to pick, I would go with liboctfortran.

Another option would be to simply merge libcruft with liboctave.

Do we also want to split up liboctave in some way?  I can easily see
justification for splitting it up into a number of convenience
libraries:

  libarray    all the Array, NDArray, Matrix, and Sparse code

  libcruft    crufty old fortran code (split this into individual
              component libraries if you prefer and completely
              eliminate the name libcruft)

  libsystem   OS related things

  libmath     math functions

  libutil     utility functions not related to arrays, OS system calls
              or numerics

All these would just be used for convenience and to aid in
understanding what is where, similar to the current setup with
liboctinterp.

jwe