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

[Tony Theodore]

On 26 Feb 2014, at 04:57, John W. Eaton <address@hidden> wrote:

> 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.

It’s a long standing issue (https://github.com/mxe/mxe/issues/145) that isn’t 
solved yet, We’ve found that native builds are harder to reliably across all 
systems and makes us duplicate the work of the various package managers.

> 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?

It’s not advertised, but we have a handful of native tools (including 
autotools) that have only been tested on OSX. Run:

make build-requirements
or
make automake MXE_TARGETS=`./ext/config.guess`

to test it out - should be sufficient for the time being, but the invocation 
will likely change in the future. We do plan to have optional “sections” that 
could be used for things like tools and non-free packages. I don’t want to add 
many more tools until this is sorted out, but if you need more at the moment, 
they should be easy enough to add using the $(PKG)_BUILD_$(BUILD) rule.

> 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.

More on native builds below, MSYS isn’t out of the question but I’ve never been 
able to get it working or it’s very slow.

> 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.

Sounds good, we can look at it down the track

> 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.

I’ve had these working by manipulating the target specific DEPS and host/target 
but it needs more work. I’m trying to get away without build-* packages and 
using target deps instead. Most packages don’t “really” depend on gcc and I’m 
trying to work out a new way of specifying the build stages (native tools, 
cross toolchain, host libraries, host tools) and let make sort out the order.

> 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?

No, we plan to support mingw.org for the foreseeable future, we’ll have the new 
v4 soon and may keep the v3 around if people need it. I hear anecdotes that 
some projects are no longer supporting mingw.org and if that turns out to be 
true, then we can selectively disable the target. If you only set the *-w64-* 
targets, it shouldn’t download the mingw.org packages so this shouldn’t have 
any impact on people using a single toolchain.

> 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?

Yes, I guess this a logical extension of the native tools and really like the 
idea of MXE being able to bootstrap itself from a very low level. Even if we 
never need to go the LFS route, I eventually want to add glibc and do a 
cross-LFS.

Cheers,

Tony