Re: [OctDev] complex error function

[Steven G. Johnson]

On 11/21/12 11:47 AM, Jordi Gutiérrez Hermoso wrote:
> But after you do the patch, how will we incorporate it back into our
> own codebase, if we have a copy of it?

"cp Faddeeva.cc octave/...../Faddeeva.cc" is pretty easy...


> I'd rather just link to your
> library than to have cut-and-paste code.

The question is ease for users, not for us.  Libraries are easy for both 
of us.  But installing an additional prerequisite library is painful for 
users.  You either:

1) force everyone to install the library.  Pain for countless users 
instead of the pain of "cp" for us.

2) make it optional.  In which case most users won't install it (at 
least, not until it is included in distros by default, which may take a 
long time even if Octave suggests it, and even then only for GNU/Linux 
distro users), and the core Octave functionality will vary with 
installation.

> release a library and make releases, maintain sonames, use a proper
> build system, and do all of that bureaucratic boring stuff called
> "software distribution", I would be much happier to include this in
> Octave, as would other non-Octave users of your code.
>
> If you wish, I can help you with setting up the software distribution
> mechanism.

I know how to distribute libraries.  You are already using a little 
library of mine called FFTW.

> Octave builds for Windows, Mac OS X, most flavours of GNU, some BSDs,
> and the occasional AIX, Solaris, and HP-UX here and there. Does your
> Makefile work on all of those, on all versions of possible libc's and
> compilers that it may encounter? If yes, then autotools is overkill.
> If not, build systems suck, but we have to use them.

In practice, a single Makefile + a compiled binary for Windows will work 
for 99.99% of users (Windows, GNU, BSD, and OSX) these days.  Or a 
single cmake file, for that matter.  It's pretty rare to encounter 
Solaris, and AIX, HP-UX users these days, and the few one does encounter 
will be able to modify a 4-line Makefile to use the appropriate 
compilers and flags on their systems (even assuming they don't just have 
gcc).  The point is, compiling one file, with no special portability 
requirements, is easy.

Going the autotools route, the configure script and Makefile will 
probably be 10 times the size of the source code, and you'll still need 
a separate binary for Windows users who don't understand Unix build tools.

> I very much do not want to do this. This is how we ended up with this
> Arpack situation, and I don't want to start doing this again:

It's bad to have no upstream and multiple downstreams, I agree, but that 
seems orthogonal to whether it is distributed as a library or as source 
code.  I don't follow you.

--SGJ