octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [OctDev] complex error function


From: Jordi Gutiérrez Hermoso
Subject: Re: [OctDev] complex error function
Date: Wed, 21 Nov 2012 11:47:48 -0500

On 21 November 2012 11:30, Steven G. Johnson <address@hidden> wrote:
> On 11/21/12 11:11 AM, Jordi Gutiérrez Hermoso wrote:
>>
>> It matters from a maintainership and code ownership perspective. If
>> you're just making a library, why not actually just create such a
>> library and you go through the hassle of making releases instead of us
>> gluing your code into Octave? I sure don't want to have to keep two
>> different copies of the same code in different codebases each with its
>> own diverging set of bugs. Then we can maintain the Octave-specific
>> wrapper ourselves and you can keep maintaining your library.
>
>
> I certainly don't want you to have a diverging set of bugs; regardless of
> how this is incorporated into Octave or OF (assuming it is), I would hope
> that you would contact me regarding bug reports and patches.

But after you do the patch, how will we incorporate it back into our
own codebase, if we have a copy of it? I'd rather just link to your
library than to have cut-and-paste code. Since both you and I are
lazy, it's imperative to set up something right now that will require
the least amount of maintenance possible from both of us. So, if you
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.

> On my side, I will plan to notify you if I have any bugfixes or
> other relevant updates on my end. I have already been doing that for
> SciPy.
>
> As I said in my other email, it is no trouble for me to provide a
> library; this is just a four-line Makefile on my end (well, a bit(!)
> larger if I use autotools, but that is probably overkill).

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.

> However, the problem on your end is then getting people to install a
> new library that no one has ever heard of.

They already do this for a bunch of other libraries. One more is a
drop in a bucket. Additionally, it would also make it easier for Scipy
and whoever else cares to use this to just link to your library and
maintain their own minimal wrapper to it.

> The alternative would be to do what SciPy is doing: include my
> Faddeeva.cc file verbatim, write your Octave-specific glue in a
> separate file, and incorporate upstream changes as needed.

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:

    http://jordi.inversethought.com/blog/arpack-situation/

- Jordi G. H.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]