Mercurial > mxe-octave
view README @ 6721:101bdb40aa4b
* src/of-control.mk: update to v3.6.0
author | John Donoghue <john.donoghue@ieee.org> |
---|---|
date | Sun, 21 May 2023 21:12:15 -0400 |
parents | ecad9fe83f88 |
children |
line wrap: on
line source
HISTORY ======= mxe-octave was forked from the MXE project(http://mxe.cc) in November 2012 when I was looking for a reliable way to cross-compile Octave for Windows. At the time, the MXE developers did not seem interested in modifying MXE to build shared libraries (. Since then, MXE has been modified As stated here: http://lists.defectivebydesign.org/archive/html/mingw-cross-env-list/2013-10/msg00006.html I never intended to permanently fork MXE, I was only looking for a way to build Octave and all its dependencies, primarily for Windows systems. Later, I needed to build Octave for old RHEL and SuSE systems that did not have sufficiently recent versions of the build tools or other dependencies. Adapting MXE to handle native builds seemed like a reasonable solution at the time, but there always seem to be issues with replacing many (but not all) system libraries that are needed to support Octave. At what point do you stop? You probably don't want to build your own OpenGL, X11, or C libraries, and mxe-octave does not attempt to build these. FUTURE ====== Now that MXE supports static and shared library builds for 32- and 64-bit Windows systems, it might be good to consider using MXE directly and abandon the mxe-octave fork, at least for Windows builds. Instead of mxe-octave duplicating all that MXE does, we could use MXE to build the cross tools and cross compile the libraries. Everything else could be built using those tools. We might still end up with some duplication, but we would For native builds, I'm not sure what the best option is. Many things could be simplified in mxe-octave if cross compiling and supporting Windows were not required, but there would still be a lot of overlap with MXE. Another option is to use docker, but older kernel versions may not support it properly. For example, for RHEL 6, docker is apparently only supported using the EPEL packages, and if people were able to use EPEL, then they could probably get dependencies that are new enough to build Octave. I my experience, people using these old systems are not willing to use packages from EPEL or similar projects. John W. Eaton jwe@octave.org 2017-04-11