Re: Octave/Win32 update

[David Bateman]

address@hidden wrote:
>> Another way around this problem is for Octave to provide wrappers for
>> all these kinds of functions, and only expose the interface to the
>> wrappers in its header files. But that's more work, and I'm not sure
>> it is worth the effort. Or, we could severely limit the external API
>> and just tell people to use feval if they want to use any function
>> that is defined inside Octave (similar to mexCallMATLAB).

I think we should make every attempt to hide the support libraries
behind the octave API. This means that the files that would need to be
included in a build of a user oct-file must not include the external
libraries headers...

However, this can be done gradually as the problems arise.

> Normally, if you only use octave API, you only need the support files for
> octinterp/octave/cruft. Other support files (I mainly mean .lib and .h
> files)

We don't really have a true API yet, which is probably the real problem.
If we had only and only exposed the needed functions, then I suppose all
of these problems would go away.. Though there is a large amount of work
is creating and documenting such an API and then sticking to it (an API
that changes all the time is not that useful).

>
> Here's a list (+/- exhaustive) of support libs I recompiled with MSVC,
> in order in importance (according to me):
> Core numerical libs
>     - BLAS
>     - LAPACK
>     - FFTW (this one, I didn't recompile, but used the available binary)
>     - HDF5

What no UFSparse or SuiteSparse on that list? In any case it seems like
it is there as colamd, \ and the qr functions all seem to work on sparse
matrices..

Regards
D.