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

[Tony Theodore]

On 25 Feb 2014, at 15:58, John W. Eaton <address@hidden> wrote:

> On 02/24/2014 11:26 PM, Timothy Gu wrote:
> 
>> BTW, it'll be nice if someone add OpenBLAS to MXE as it is BSD-licensed.
> 
> We've done that for Octave's fork of MXE.  The rules will need to be modified 
> slightly to fit back in MXE itself, but it should be fairly straightforward.  
> I should be able to do that but it may take a day or two for me to find the 
> time.
> 
>  http://hg.octave.org/mxe-octave/file/26bd1899d7a7/src/openblas.mk

Thanks!

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]. The target cpu detection and enabling openmp 
need some investigation, but it's otherwise good to go and builds on all six 
targets.

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.

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.

From a coding perspective, the main difference is that we don’t use make’s 
pre-processor conditionals, using functions instead. Since we use 
target-specific-varaiables [4] instead of globals for many rules, the 
pre-processor style doesn’t work well as many variables can’t be evaluated till 
they’re about to be executed. This means that something like:

    ifeq ($(ENABLE_64),yes)
        $(PKG)_MAKE_OPTS += BINARY=64
    else
        $(PKG)_MAKE_OPTS += BINARY=32
    endif

translates to:

    $(PKG)_MAKE_OPTS = \
        ...
        BINARY=$(if $(findstring x86_64,$(TARGET)),64,32)

and also means that operators like “+=“ can’t be used in this context. We’ve 
recently added the GNU Make Standard Library [5] which has inline logical 
operators (among other handy functions), but so far I haven’t used them.

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

at this stage, you should be able to run the rest of your builds using the 
MXE-built libs (and “touch”ing the install markers), and we’ll be better able 
to assess the things that will make downstream MXE customisations more 
flexible/merge-able/possible.

Your thoughts?

Cheers,

Tony


[1] https://github.com/mxe/mxe/commit/444589864432537b9094233ba4f0225bd853b54b
[2] gl2ps glpk gnuplot pstoedit qhull qrupdate qscintilla texinfo
[3] hdf5 lapack blas cblas pdcurses readline suitesparse
[4] http://www.gnu.org/software/make/manual/make.html#Target_002dspecific
[5] http://gmsl.sourceforge.net/