octave / octave-devel @3.4.2 updated portfile

[lukas.reichlin@…]

I've created a patch for octave-devel. It builds the most recent version of octave (version 3.4.2, released today) and supports the new FLTK backend. I removed some configure args which were not necessary according to octave's main author jwe.

Best regards Lukas

[lukas.reichlin@…]

The Patchfile

[lukas.reichlin@…]

The entire new Portfile

[lukas.reichlin@…]

Cc Me!

[jmroot (Joshua Root)]

Please remember to fill in the Port field and cc the maintainer. You do not need to be in cc when you are the reporter. As per the ticket guidelines, since this is an update of an existing port and not a submission of a new port, the appropriate ticket type is "update".

[michaelld (Michael Dickens)]

Fixed in r79770. I kept FLTK as a variant for now, and went back to gcc4 as the default compiler variant since that is what is still used by atlas and arpack. I also kept in the +debug variant, just in case ... Thanks for pointing out this update! I wish GNU had an RSS feed for Octave; I follow feeds for most of my ports, but I've never found one for this port.

[lukas.reichlin@…]

Thanks. Below you find the jwe's advice on my patched portfile for release candidate 1:

On 21-Jun-2011, Lukas Reichlin wrote:

| I've built octave-3.4.2-rc1 successfully on Mac OS X 10.6.7 using a
| modified version of MacPorts' octave-devel Portfile (attached).
| I've chosen the +gcc45 option.  I'm able to compile and run
| successfully my oct-files from the control package.

Thanks.

Here are a few comments about the options you are using:

| configure.args      --without-x \
|                     --enable-shared \
|                     --enable-dl \
|                     --disable-docs \
|                     --disable-openmp

Both --enable-shared, --enable-dl, and --disable-openmp are defaults,
and the --enable-openmp appears to have no effect anyway.

| ### the following are probably not necessary (except possibly the
| ### 'cholmod' one), but are included for completion.  Ordering is the
| ### same as in './configure --help'.
| configure.args-append \
|                     --enable-readline \
|                     --enable-extra-warning-flags \
|                     --with-qhull \
|                     --with-z \
|                     --with-hdf5 \
|                     --with-fftw3 \
|                     --with-fftw3f \
|                     --with-glpk \
|                     --with-curl \
|                     --with-blas \
|                     --with-lapack \
|                     --with-qrupdate \
|                     --with-amd \
|                     --with-camd \
|                     --with-colamd \
|                     --with-ccolamd \
|                     --with-cholmod="-lcholmod -lmetis" \
|                     --with-cxsparse \
|                     --with-umfpack \
|                     --with-arpack

These are defaults except for the --with-cholmod="-lcholmod -lmetis"
option, and that should not be used if you are building a binary for
redistribution since the METIS library is not distributed under terms
that are GPL compatible.

| ### the following are probably not necessary, but are included for
| ### completion.
| # octave uses a number of other ports to create sources from template:
| # perl, gawk, gsed, flex, bison, texinfo.  python is not used if perl
| # is available, so clear it out.  FLTK doesn't work as of 1.3.x-r7794,
| # so disable it entirely (via "no" here and a configure patch).
| configure.perl      ${prefix}/bin/perl
| configure.python    ' '
| configure.awk       ${prefix}/bin/gawk
| configure.env-append SED="${prefix}/bin/gsed" \
|                      TEXI2DVI="${prefix}/bin/texi2dvi" \
|                      TEXI2PDF="${prefix}/bin/texi2pdf" \
|                      FLTK_CONFIG=no

Except for FLTK_CONFIG=no the configure script should find these, so
there should be no need to specify them.

| variant debug description {Produce debugging information in compiled code} {
|     configure.cflags-delete    -O2
|     configure.cxxflags-delete  -O2
|     configure.fflags-delete    -O2
|     configure.fcflags-delete   -O2
|     configure.f90flags-delete  -O2
|     configure.objcflags-delete -O2
|     configure.cflags-append    -g3 -O0
|     configure.cxxflags-append  -g3 -O0
|     configure.fcflags-append   -g3 -O0
|     configure.f90flags-append  -g3 -O0
|     configure.fflags-append    -g3 -O0
|     configure.objcflags-append -g3 -O0
| }

What is the effect of this?  If you are disabling compiler
optimization when building Octave, then you are really making it much
slower.  To get good performance, Octave depends heavily on code
inlining and other compiler optimizations which I think will not
happen with -O0.

jwe

I don't know of any RSS feeds for octave, but there are two mailing lists (help and maintainers) you may want to subscribe to:
​http://www.gnu.org/software/octave/archive.html

I've got four questions/remarks:

1. Is there a reason why you use the patch-configure.diff patchfile even when the FLTK version is chosen?
   
2. Is it possible to create a (default) variant for the gnuplot graphics toolkit such that one can choose between FLTK and gnuplot?
   
3. When will octave 3.4 become "octave" instead of "octave-devel"?
   
4. There are many outdated octave packages available from MacPorts. One could use the new pkg command within octave, e.g.
   

pkg install -forge odepkg

Regards Lukas

[michaelld (Michael Dickens)]

Lots to answer! I'm glad you're keeping up with Octave, since I don't really have the time to.

A) I agreed with your changes to remove the --with and --enable configure flags. Looking at the output of "./configure --help" shows that those flags are the defaults and thus aren't needed; or that they don't do anything. Good.

B) The MacPorts configure options (e.g., "configure.perl") are still needed, since the 'configure' script picks up that provided by Apple instead (e.g., in /usr/bin ). I'd prefer to use known programs, and thus choose to use those provided by MacPorts. No drama though.

C) I don't know if the licenses for Octave and any of its dependencies conflict. That's above my pay grade and IANAL. TINLA: I can say that MacPorts in and of itself does not violate licenses, since it is not immediately distributing tarballs (except its own) or binaries, and, TTBOMK, does not form a greater work with respect to any ports it might install. The burden really is on the end-user who is telling MacPorts to install various ports, for him/her to figure out how to deal with multiple, possibly conflicting, licenses if/when he/she decides to distribute some greater work. That said, the MacPorts project does try to provide variants such that it should be clear to the end-user whether licenses are possibly conflicting. See, e.g., 'port info ffmpeg'.

D) If someone -really- wants to debug octave, they'll need to compile with -O0 to remove optimization including inlining, and add in debugging to the libraries via -g#. I pick -g3 for the max debugging info, supposed to be placed into the libraries such that one doesn't entirely need the original source code any longer (since it generally won't be around after MacPorts installs the port). Maybe there is a better way, but this worked for me once upon a time. Maybe octave has become stable enough that this variant is no longer necessary?

1) The default 'configure' script will always check for FLTK; if it finds fltk-config in the PATH, then it will try to use it, no matter any other configure options. The patch-configure file corrects this behavior and allows the use of a shell environment variable to completely disable fltk checking. While I could split this patch into 2 parts -- one for if doing +fltk and another if not -- it works either way and so I'm just leaving it as is until the Octave folks get around to augmenting their side.

2) Default to gnuplot: probably. Please feel free to figure out how to do this & submit another ticket with a patch. I don't have time to work this issue out, for many months down the road.

3) Don't know. Could be a while, since that would be a major change in MacPorts' various octave-dependent ports. I think this decision is above my pay grade.

4) OK; good to know about. I don't use Octave very often any longer, so I haven't kept up with these changes.