Re: Patches to enable MSVC compilation

[Michael Goffioul]

On Tue, Dec 8, 2009 at 8:46 PM, John W. Eaton <address@hidden> wrote:
> It's not like we are rejected every portability patch.  So I think it
> does make sense to continue submitting them so as to minimize the
> number of external patches you would have to maintain.

There's always only one patch. I just split it up into logical parts
to make your life easier.

> I also don't see any reason not to put the required patches in a
> public place.

That's why I said that anybody that wants the patch can
contact me. But to be honest, since I started to work on
MSVC support, I only recall one person who wanted to
compile octave with MSVC.

> As I recall, there is nothing preventing people from
> building Octave with MSVC.  The problem is that we can't provide a
> binary distribution compiled with MSVC and linked with MSVC run-time
> libraries without violating the terms of the GPL.

IIRC, it's even more simple: you can compile and link octave
against runtime libraries, but you can't distribute them in the
same binary (iirc, that aws the conclusion from FSF as contacted
by the guy who complained). But it doesn't matter now.

> But I have no
> objection to making it possible (and even relatively easy) for people
> to compile Octave with MSVC.

Trust me, it's definitely not easy to compile octave with MSVC.
And with the move to libtool and gnulib, it's just harder.
But that's fine, usually I always find tricks to work around problems.

> But there are limits, so if there is
> something that causes a lot of trouble for Octave maintenance, or
> would mean worse performance for all Octave users, then I'd rather not
> make the change, or at least it should be conditional in some way.
>
> I haven't looked closely at the patch, but would it be possible to
> have a conditional that allows us to integrate your changes to avoid
> the MSVC bug, but only for MSVC?

Jaroslav answered this. It's too invasive and I fully agree.
Note that I never intended to
have the offending patch applied as-is. I knew it'd be rejected. It was
more to show the problem and *one* workaround. There are probably
better ways to do that, but I don't have the time neither the template
expertise to do it. Note that MSVC *can* deal with function or inner
types or overloaded functions in template parameters, but it seems
that in this specific case, it's too complex for it.

Michael.