Re: Renaming libcruft

[Rik]

On 08/24/2012 09:07 AM, John W. Eaton wrote:
> | 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.
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.
>
> 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)
I would keep the code together since it is a very distinct entity and makes
a natural convenience sub-library for liboctave.  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.
>
>   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
>