octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: How to compile e.g., tip in MXE


From: John W. Eaton
Subject: Re: How to compile e.g., tip in MXE
Date: Fri, 01 Mar 2013 08:42:58 -0500
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.11) Gecko/20121122 Icedove/10.0.11

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]