Re: [Mingw-cross-env-list] Merging MXE Octave - first steps (was What gets compiled into DLL by libtool (licencing issues))

[John W. Eaton]

On 02/25/2014 07:05 AM, Tony Theodore wrote:
> On 25 Feb 2014, at 15:58, John W. Eaton <address@hidden> wrote:
>
> Now that we can do shared builds, I thought I’d take the opportunity
> to have a look at what we can start doing to combine our
> efforts. Openblas was very straightforward - all that was required
> was stylistic (see below on coding) changes and it’s now added
> [1].

Thanks.

> I’m hoping the remaining Octave deps [2] should be similarly
> straightforward, there’s still some work to enable shared builds for
> the existing packages [3], but we should be able to build a
> “default" Octave in the near future.

I started looking at this a few days ago and ran into some problems.
One issue was that a package (I think glpk or arpack, but I'm not
sure) needed an autoreconf step and it failed because the version of
autotools on my system was too old (even though I'm using a fairly
current Debian testing system, it still has older versions installed).

With mxe-octave, I know that there will be current autotools versions
available because we build them as part of the build process.
Likewise for (nearly) all the build tools.  We do this so that we have
better control over the tools instead of relying on whatever happens
to be installed on the system.  I found that was necessary when trying
to do native builds on old RHEL and SuSE systems (more below on why I
was doing this).  Would you be interested in doing something similar
for MXE?

> As for the build system - Wow! You’ve turned the Makefile into an
> autotools Makefile.in and have native builds, customisation options,
> msvc toolchain, packaging (and …?). There’s some work-in-progress on
> native builds and customisation, but we’ve gone in very different
> directions here and it will be hard to incorporate all that - some
> of it is well out of our scope.

I'm not expecting that we could merge everything.  Certainly not
automatically.  I'd be glad if we could just get to the point where
MXE could cross compile Octave for 32- and 64-bit Windows systems
using the same toolchain for both.  A nice bonus would be to allow
native builds on Windows systems using MinGW/MSYS.  I don't think
that's a big leap, but as I recall does require some changes in the way
$(PREFIX)/$(TARGET) is handled.  The packaging and other things
specific to Octave could be a separate layer on top of MXE.

Since we already have something that sort of works for Octave, I'm in
no rush at all.  It can be done incrementally, and I'm willing to help
do whatever I can.  I'm definitely not expecting you or anyone else to
take on this job.

> From a coding perspective, the main difference is that we don’t use
> make’s pre-processor conditionals, using functions instead.

I'm sure your approach is more flexible and I have no argument with
it.  I did what I did because it was something I knew how to do.

> Since you have both a customised MXE and customisable packages, I
> think the way forward (from MXE’s perspective) is something like:
>
> -enable shared builds for existing Octave dependencies
> -add remaining deps
> -build default Octave
> -understand subtleties of config options (can be deferred)
> -finalise customisation “classes" and hook points
> -build custom Octave

Seems reasonable to me.

Another thing that Octave needs is the build tools running on the
Windows system.  We need the same set of tools that were used to build
Octave so that people can build plug-ins for Octave on their Windows
systems.  That's why we have build-gcc and native-gcc packages.  I'm
not sure of the best way to integrate that sort of thing with MXE.

Also, mxe-octave is now using mingw-w64 for both 32- and 64-bit
systems so we aren't downloading binary bits for the mingw runtime
libraries.  Are you also headed in that direction?

About the native RHEL and SuSE builds: there are many business folks
who are using RHEL 5.x or SuSE 10.x systems that have old versions of
GCC and that don't provide packages for very many Octave dependencies.
So it seemed easier to try to modify MXE to do native builds for those
systems than to write something completely new.  That we were able to
make it work shows that the flexibility is there.  I know this is
outside of the scope of what you are trying to do and I'm not saying
that you should support it, or even feel obligated to support it in
any way.  But if it is possible to do it just by generalizing a few
more things, would you be interested?

jwe