Re: Performance issues on Windows, suggests a MSVC build

[Jordi Gutiérrez Hermoso]

2011/6/27 John W. Eaton <address@hidden>:
> On 27-Jun-2011, Jordi Gutiérrez Hermoso wrote:
>
> | Except building on Debian and Ubuntu is loads easier than building on
> | Windows. We really lost some steam when Rafael Laboissiere retired
> | from Debian packaging, but you and I regularly build on Debian, and we
> | know it's not that bad.
> |
> | I'll work on the Debian packages this week, with some moderately
> | high priority.
>
> I probably don't understand the issues involved in building binary
> packages (for Windows, Debian, OS X, or any system) but it seems to me
> that once set up, it should be fairly trivial to generate the next
> one.  Can you briefly explain why this is not the case?

I can tell you about building Debian packages, which is all I've ever
done. I don't know how much of this applies to Windows.

There is in, fact, something along the lines of what you describe for
Debian packaging. It's the debian/rules Makefile script that handles
the steps of building a Debian package. You can see our current
version of it here:

    
http://anonscm.debian.org/gitweb/?p=pkg-octave/octave.git;a=tree;h=3b944c117163c0448616ce1c0f8adc9a18dca50f;hb=3b944c117163c0448616ce1c0f8adc9a18dca50f

As you can see, since Debian builds on 9 architectures or so, we have
to make sure it builds on those. For the moment, this involves
dropping debugging symbols and some MIPS-specific hacks. I'm reading
through the file and I'm also seeing several references of how things
changed peculiarly to the 3.0 series. We also have a legacy layout of
having separate 3.0 and 3.2 packages back when it made sense to have
several versions of Octave packaged for Debian for whatever reason.
There are plans to drop that, and uniting the packages under a generic
"octave" package will involve some work.

Some months ago Thomas Weber and others discussed the plans for an
updated packaging:

    
http://lists.alioth.debian.org/pipermail/pkg-octave-devel/2011-February/007699.html

It's not just a matter of sorting out dependencies. We also have
several bugs to ponder:

    http://bugs.debian.org/octave3.2

We have to see how this will impact all of the Octave-Forge packages,
and any other Debian packages that depend on Octave:

    address@hidden:~$ apt-cache rdepends octave3.2 | grep -v octave | sort | 
uniq
    dynare
    education-mathematics
    fsl-4.1
    med-physics
    pfstools
    python-scitools
    science-mathematics
    science-numericalcomputation
    science-robotics
    sdpam
    shogun-elwms
    xmds

There's also the issue that Octave now properly handles sonames, i.e.
we have a library to take care of now. Library packaging involves some
rituals of its own, like maintaing a debian/symbols file for the
benefit of any other Debian packages that build against this library,
as presumably some of the above non-Octave packages do.

In short, there's a bunch of fiddly things we have to make sure of in
order to comply with Debian policy and proper place of Octave within
the Debian system. Ubuntu cares less about some of these things (e.g.,
only 2 architectures), so I wouldn't be too surprised if someone gets
around to making an Ubuntu-specific package that doesn't follow strict
Debian policy, as has happened with the qtoctave packages.

I imagine similar things must happen for Windows, or that it has
packaging complications of its own. My overall point is that just
ensuring the thing builds isn't enough.

- Jordi G. H.