How to compile e.g., tip in MXE

[Philip Nienhuis]

How can I (try to) get a more recent Octave dev version (perhaps a tip) compiled in/with MXE?

Swapping in 3.6.4 instead of 3.6.4-rc2 was easy, but for a tip the MXE insists on a download. No matter what I try, it'll always get the 3.7.2 snapshot from alpha.gnu.org.
The "file:///" protocol apparently isn't supported. I could set up a local ftp server but there must be an easier way.

Thanks,

Philip

[John W. Eaton]

On 02/28/2013 05:47 PM, Philip Nienhuis wrote:
> How can I (try to) get a more recent Octave dev version (perhaps a tip)

In Mercurial, "tip" just means the most recent changeset in your
archive.  It may not be the same as "tip" in another archive, even if
they have an equivalent set of changesets.

> compiled in/with MXE?
>
> Swapping in 3.6.4 instead of 3.6.4-rc2 was easy, but for a tip the MXE
> insists on a download. No matter what I try, it'll always get the 3.7.2
> snapshot from alpha.gnu.org.
> The "file:///" protocol apparently isn't supported. I could set up a local
> ftp server but there must be an easier way.

I've updated my mxe-octave archive for 3.6.4.  But for the record here
is what you need to do to switch to a new version of a package using
MXE:

   * edit index.html, find the package you are working with and change
     the version number.  For the 3.6.x series, you should use the
     "stable-octave" package, not the "octave" package.  The "octave"
     package will build dependencies you don't need, like Qt and LLVM.

   * put a copy of the new source tarball in the pkg directory and
     compute sha1sum for it.

   * edit the src/stable-octave.mk file and insert the sha1sum for the
     new version of the package on the appropriate line.  Also check to
     see whether there are any special rules in the makefile fragment
     that no longer apply to the new version of the package or whether
     there are any new rules that may need to be added to handle the
     new package.

   * check to see whether there are any patch files in the src/
     directory for the package and whether they still make sense for
     the new version.  If not, remove them.  If you need new patches,
     add them.  The file names follow the pattern src/PKG-*.patch.

   * try to build the package.

Iterate over the above steps until the build succeeds.  If it fails,
you will have a log/PKG file and a tmp-PKG directory that you can
examine to determine what failed and why.

jwe

[Philip Nienhuis]

John W. Eaton wrote

On 02/28/2013 05:47 PM, Philip Nienhuis wrote:
> How can I (try to) get a more recent Octave dev version (perhaps a tip)

In Mercurial, "tip" just means the most recent changeset in your
archive.  It may not be the same as "tip" in another archive, even if
they have an equivalent set of changesets.

> compiled in/with MXE?
>
> Swapping in 3.6.4 instead of 3.6.4-rc2 was easy, but for a tip the MXE
> insists on a download. No matter what I try, it'll always get the 3.7.2
> snapshot from alpha.gnu.org.
> The "file:///" protocol apparently isn't supported. I could set up a local
> ftp server but there must be an easier way.

I've updated my mxe-octave archive for 3.6.4.  But for the record here
is what you need to do to switch to a new version of a package using
MXE:

   * edit index.html, find the package you are working with and change
     the version number.  For the 3.6.x series, you should use the
     "stable-octave" package, not the "octave" package.  The "octave"
     package will build dependencies you don't need, like Qt and LLVM.

   * put a copy of the new source tarball in the pkg directory and
     compute sha1sum for it.

   * edit the src/stable-octave.mk file and insert the sha1sum for the
     new version of the package on the appropriate line.  Also check to
     see whether there are any special rules in the makefile fragment
     that no longer apply to the new version of the package or whether
     there are any new rules that may need to be added to handle the
     new package.

   * check to see whether there are any patch files in the src/
     directory for the package and whether they still make sense for
     the new version.  If not, remove them.  If you need new patches,
     add them.  The file names follow the pattern src/PKG-*.patch.

   * try to build the package.

Iterate over the above steps until the build succeeds.  If it fails,
you will have a log/PKG file and a tmp-PKG directory that you can
examine to determine what failed and why.

Thanks.
For 3.6.4 I've already did those steps - that was a simple matter of indeed editing index.html, fixing the src/octave.mk file by inserting a new checksum (openssl sha1 <file>) and changing the download dir (package URL) to that where the stable 3.6.4 version is.
(That MXE-built 3.6.4 works quite good BTW.)

However I'd like to try to build a "tip" (or recent version) of the default branch. That failed, as no matter what I tried I consistently got the 3.7.2 snapshot you made a while ago - it is downloaded quite autonomously by some other command in the MXE tree.
I couldn't find where that download is initiated so that I could circumvent it for octave itself. Grepping for "[download]" (one of the repeated messages during an MXE build) didn't help me.

(I made a "snapshot" by hg-cloning the default octave branch, doing a ./bootstrap inside, and tar/zipping it. Maybe naive, but it is just a start)

Philip

[John W. Eaton]

On 03/01/2013 01:53 PM, Philip Nienhuis wrote:

> However I'd like to try to build a "tip" (or recent version) of the default
> branch. That failed, as no matter what I tried I consistently got the 3.7.2
> snapshot you made a while ago - it is downloaded quite autonomously by some
> other command in the MXE tree.
> I couldn't find where that download is initiated so that I could circumvent
> it for octave itself. Grepping for "[download]" (one of the repeated
> messages during an MXE build) didn't help me.
>
> (I made a "snapshot" by hg-cloning the default octave branch, doing a
> ./bootstrap inside, and tar/zipping it. Maybe naive, but it is just a start)

Make a regular distribution tarball with "make dist".  Then do the same
for this new version as you did for 3.6.4.

I don't have a shortcut for building from hg yet.  If you decide to do
something along those lines instead it would be great if you would share
your changes.

The rules that perform the download steps for MXE are in the top-level
Makefile.  Search for WGET.

jwe

[PhilipNienhuis]

John W. Eaton wrote

On 03/01/2013 01:53 PM, Philip Nienhuis wrote:

> However I'd like to try to build a "tip" (or recent version) of the default
> branch. That failed, as no matter what I tried I consistently got the 3.7.2
> snapshot you made a while ago - it is downloaded quite autonomously by some
> other command in the MXE tree.
> I couldn't find where that download is initiated so that I could circumvent
> it for octave itself. Grepping for "[download]" (one of the repeated
> messages during an MXE build) didn't help me.
>
> (I made a "snapshot" by hg-cloning the default octave branch, doing a
> ./bootstrap inside, and tar/zipping it. Maybe naive, but it is just a start)

Make a regular distribution tarball with "make dist".  Then do the same
for this new version as you did for 3.6.4.
<snip>
The rules that perform the download steps for MXE are in the top-level
Makefile.  Search for WGET.

I'm sorry for some n00b questions.

I couldn't find how to invoke "make dist" from a just cloned hg repo. What do I need to do to get that far? AFAICS I'd need to bootstrap & configure before a Makefile with "dist" target is present.

As to the MXE build: after running ./bootstrap and copying in some files (Changelog, AUTHORS, etc., copied from a simultaneous Linux build) and tarzipping them + copying into mxe-octave/pkg the build goes OK until:

(I've run with " --jobs 2" so I guess a few messages have been mixed up)
:
../../run-octave -f -q -H -p /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/doc/interpreter --eval "geometryimages ('voronoi', 'eps');"
mv vectorize.texi-t vectorize.texi
../../run-octave -f -q -H -p /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/doc/interpreter --eval "geometryimages ('triplot', 'eps');"
/home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/libtool: line 10095: /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/src/octave: No such file or directory
make[5]: *** [voronoi.eps] Error 127
make[5]: *** Waiting for unfinished jobs....
/home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/libtool: line 10095: /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/src/octave: No such file or directory
make[5]: *** [triplot.eps] Error 127
make[5]: Leaving directory `/home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/doc/interpreter'
make[4]: *** [install-recursive] Error 1
make[4]: Leaving directory `/home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/doc'

...which I suppose is due to the file suffixes of octave.exe etc. not matching what the 'run-octave' command expects - in file <builddir>/run-octave I see:
octave_executable="$builddir/src/octave"
rather than
octave_executable="$builddir/src/octave.exe"

All four octave binaries (octave.exe/octave-cli.exe/mkoctfile.exe/octave-config.exe) were built so at least that looks good, it's a postprocessing step (building the docs) that fails.
oct-files weren't made yet (couldn't find them in the tree).

What can I do to get further in the MXE build?

Thanks,

Philip

[John W. Eaton]

On 03/02/2013 05:05 PM, PhilipNienhuis wrote:

> I couldn't find how to invoke "make dist" from a just cloned hg repo. What
> do I need to do to get that far? AFAICS I'd need to bootstrap&  configure
> before a Makefile with "dist" target is present.

Yes, you have to configure and build everything before you can build the
distribution tar file.  That's necessary because you have to build
documentation files, and the figures for the documentation are created
with Octave.  So you need

   ./bootstrap && ./configure && make all dist

> mv vectorize.texi-t vectorize.texi
> ../../run-octave -f -q -H -p
> /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/doc/interpreter
> --eval "geometryimages ('triplot', 'eps');"
> /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/libtool:
> line 10095:
> /home/philip/devel/octdev/mxe/mxe-octave/tmp-octave/octave-3.7.2d/.build/src/octave:
> No such file or directory

You are cross compiling Octave, so you are not expected to be able to
run Octave to build the documentation.  It works with a proper tarball
release file because the documentation in those files is already built.
  If you modify something that forces the figures in the documentation
to be rebuilt, then you need to build with --disable-docs.

jwe

[PhilipNienhuis]

John W. Eaton wrote

On 03/02/2013 05:05 PM, PhilipNienhuis wrote:

> I couldn't find how to invoke "make dist" from a just cloned hg repo. What
> do I need to do to get that far? AFAICS I'd need to bootstrap&  configure
> before a Makefile with "dist" target is present.

Yes, you have to configure and build everything before you can build the
distribution tar file.  That's necessary because you have to build
documentation files, and the figures for the documentation are created
with Octave.  So you need

   ./bootstrap && ./configure && make all dist

That's what I tried yesterday night but I got this:

:
make[1]: Entering directory `/home/philip/devel/octdev/oct371/libinterp'
make[1]: *** No rule to make target `config-featurs.sh', needed by `distdir'.  Stop.
make[1]: Leaving directory `/home/philip/devel/octdev/oct371/libinterp'
make: *** [distdir] Error 1

I figured this obviously came about because I wasn't following formal procedures; but apparently I was.
I filed a bug report for this (#38458).

Thank you,

Philip

[Michael Goffioul]

On Sun, Mar 3, 2013 at 5:21 AM, PhilipNienhuis <[hidden email]> wrote:

John W. Eaton wrote
> On 03/02/2013 05:05 PM, PhilipNienhuis wrote:
>
>> I couldn't find how to invoke "make dist" from a just cloned hg repo.
>> What
>> do I need to do to get that far? AFAICS I'd need to bootstrap&  configure
>> before a Makefile with "dist" target is present.
>
> Yes, you have to configure and build everything before you can build the
> distribution tar file.  That's necessary because you have to build
> documentation files, and the figures for the documentation are created
> with Octave.  So you need
>
>    ./bootstrap && ./configure && make all dist

That's what I tried yesterday night but I got this:

:
make[1]: Entering directory `/home/philip/devel/octdev/oct371/libinterp'
make[1]: *** No rule to make target `config-featurs.sh', needed by
`distdir'.  Stop.
make[1]: Leaving directory `/home/philip/devel/octdev/oct371/libinterp'
make: *** [distdir] Error 1

I figured this obviously came about because I wasn't following formal
procedures; but apparently I was.
I filed a bug report for this (#38458).

Looks like a typo to me.

Michael.

[John W. Eaton]

On 03/03/2013 08:40 AM, Michael Goffioul wrote:

>     make[1]: Entering directory `/home/philip/devel/octdev/oct371/libinterp'
>     make[1]: *** No rule to make target `config-featurs.sh', needed by
>     `distdir'.  Stop.
>     make[1]: Leaving directory `/home/philip/devel/octdev/oct371/libinterp'
>     make: *** [distdir] Error 1
>
>     I figured this obviously came about because I wasn't following formal
>     procedures; but apparently I was.
>     I filed a bug report for this (#38458).
>
>
> Looks like a typo to me.

Fixed.

jwe

[PhilipNienhuis]

John W. Eaton wrote

On 03/03/2013 08:40 AM, Michael Goffioul wrote:

>     make[1]: Entering directory `/home/philip/devel/octdev/oct371/libinterp'
>     make[1]: *** No rule to make target `config-featurs.sh', needed by
>     `distdir'.  Stop.
>     make[1]: Leaving directory `/home/philip/devel/octdev/oct371/libinterp'
>     make: *** [distdir] Error 1
>
>     I figured this obviously came about because I wasn't following formal
>     procedures; but apparently I was.
>     I filed a bug report for this (#38458).
>
>
> Looks like a typo to me.

Fixed.

Thanks.

Unfortunately I now get another one (after updating/bootstrap/configure/make/make check):

(make all dist)
:
make[1]: Entering directory `/home/philip/devel/octdev/oct372+/libinterp'
make[1]: *** No rule to make target `oct-parse.in.yy', needed by `distdir'.  Stop.
make[1]: Leaving directory `/home/philip/devel/octdev/oct372+/libinterp'
make: *** [distdir] Error 1

Philip

[PhilipNienhuis]

PhilipNienhuis wrote

John W. Eaton wrote

On 03/03/2013 08:40 AM, Michael Goffioul wrote:

>     make[1]: Entering directory `/home/philip/devel/octdev/oct371/libinterp'
>     make[1]: *** No rule to make target `config-featurs.sh', needed by
>     `distdir'.  Stop.
>     make[1]: Leaving directory `/home/philip/devel/octdev/oct371/libinterp'
>     make: *** [distdir] Error 1
>
>     I figured this obviously came about because I wasn't following formal
>     procedures; but apparently I was.
>     I filed a bug report for this (#38458).
>
>
> Looks like a typo to me.

Fixed.

Thanks.

Unfortunately I now get another one (after updating/bootstrap/configure/make/make check):

(make all dist)
:
make[1]: Entering directory `/home/philip/devel/octdev/oct372+/libinterp'
make[1]: *** No rule to make target `oct-parse.in.yy', needed by `distdir'.  Stop.
make[1]: Leaving directory `/home/philip/devel/octdev/oct372+/libinterp'
make: *** [distdir] Error 1

Fixed by Rik about while I was typing the previous post....

http://hg.savannah.gnu.org/hgweb/octave/rev/05313332d541

Philip