New mxe-octave organization for Windows builds (was: Re: octave.mk MXE file still necessary?)

[John W. Eaton]

On 06/25/2018 05:02 PM, Rik wrote:
> On 06/21/2018 10:35 AM, John W. Eaton wrote:
> > On 06/21/2018 12:06 PM, Rik wrote:
> > > All,
> > >
> > > I just checked the recipes for making in Octave in the MXE src/ directory
> > > and I find stable-octave.mk (4.4.0), default-octave.mk (5.0.0), and
> > > octave.mk (4.2.0-rc4).  Do we need the last recipe?  I think it is
> > > confusing because without any other information I would think to build just
> > > octave.mk, and that would get me a very out-of-date version.
> >
> > I agree that it's a bit of a mess right now.
> >
> > I'm not sure how best to manage this or what the names of the targets
> > should be, but my goals would be to allow the following four configurations:
> >
> >    * building from the current default branch in the hg archive.  As we do
> > now, it's fine with me if this requires creating a tarball from the
> > current hg sources separately from mxe-octave.  This configuration allows
> > testing for the next major release.
> >
> >    * building from the current stable branch in the hg archive.  This can
> > work the same way as for default, but just using the stable branch. This
> > configuration allows testing for the next bug-fixing stable release.
> >
> >    * A way to build the last stable released version of Octave from
> > ftp.gnu.org but with the latest mxe-octave tools and dependencies.  This
> > configuration allows us to check whether the last stable release can
> > still be built with new versions of tools and dependencies.
> >
> >    * A way to build the last stable released version of Octave from
> > ftp.gnu.org with the same versions of mxe-octave tools and dependency
> > libraries.  This configuration allows anyone to reproduce the builds that
> > we distribute.
> >
> >    * A way to build the last stable released version of Octave from
> > ftp.gnu.org but with the latest mxe-octave tools and dependencies.  This
> > configuration allows us to check whether the last stable release can
> > still be built with new versions of tools and dependencies.
> >
> >
> > At least the first two configurations should be built and tested often by
> > the buildbots.  The others are less important but seem useful to have.
> >
> > jwe
>
> Agree with all of this.  To avoid confusion, I deleted the obsolete recipe
> octave.mk.  If we want specific recipes for some of these scenarios they
> can be written with appropriately descriptive names.

I decided on the following naming scheme:

  default:  current sources from the default development branch

  stable:  current sources from the stable development branch

  release:  current released version

For stable and default, you must build a tar.lz file separately and 
place it where mxe-octave looks for package sources.  There is no 
checksum in the mxe-octave makefile fragment for these, and the package 
URL is set to an invalid location so it will take whatever tar.lz file 
you have in the package source directory as long as it has the expected 
version number (currently 5.0.0 for default and 4.0.0+ for stable).  The 
package URL is also invalid.

For the "release-octave" package there is checksum and valid URL.

Note that the release-octave package builds the released sources with 
the latest mxe-octave packages so it does not duplicate the binary 
builds that we distribute.  The comments in the release-octave.mk file 
explain how to do that:

## To reproduce the binary
## builds for Windows that are distributed on ftp.gnu.org, you must
## choose the revision of mxe-octave that matches the release you
## wish to reproduce.  Those should be tagged in the mxe-octave archive
## with tags like "octave-release-4.4.0".  The options used to build are
##
##   --enable-octave=release
##   --enable-binary-packages
##   --enable-devel-tools
##   --enable-qt5
##   --disable-system-opengl
##
## and one of the following
##
##   * 64-bit Windows build; 32-bit integers for Fortran
##     (including BLAS and LAPACK libraries) which is the typical
##     configuration for all Linux distributions:
##
##       --enable-windows-64 --enable-64 --disable-fortran-int64
##
##   * 64-bit Windows build; 64-bit integers for Fortran
##     (including BLAS and LAPACK libraries):
##
##       --enable-windows-64 --enable-64 --enable-fortran-int64
##
##   * 32-bit Windows build:
##
##       --disable-windows-64 --disable-64 --disable-fortran-int64

I've also updated the buildbots to build all nine of the possible 
combinations: (default, stable, release) X (32-bit Windows, 64-bit 
windows with 32-bit Fortran integers, and 64-bit Windows with 64-bit 
Fortran integers).

jwe