pure-octave: update to 0.8

[agraef]

Upstream release (compatibility with Octave 4.0.3+).

[Schamschula]

According to the upstream README, the current version of pure-octave is not compatible with the current MacPorts version of octave, 4.2.0 (and probably octave 4.2.1, that was released a couple of days ago).

[agraef]

That's true, I'm still working on Octave 4.2 compatibility (upstream developer here). But the 0.8 version will at least work with Octave 4.0.3, which is an improvement over the 0.7 version currently in MP which doesn't do that (and doesn't compile with Octave 4.2 either).

I hope that I can resolve the remaining issues with Octave 4.2 soon (looks like the octave_embed interface was broken in 4.2.0, other high-profile projects like R are hit by this as well, see e.g. renozao/RcppOctave#14). But this is an intricate issue involving internals of the Octave interpreter implementation, so it may well take a little while. In the meantime, pure-octave 0.8 version gives MP Pure users a migration path since they may stick to Octave 4.0.3 a bit longer (which still builds and runs fine with MP, if you just check out the 4.0.3 version of the Portfile). That's what I'm doing myself right now.

[agraef]

@Schamschula, sorry, I thought that the 0.8 version would at least build with Octave 4.2.0, because it contains some fixes for that, too. It certainly builds with Octave 4.2.0 on Linux. But it seems that there are some additional Mac-specific issues there, too. Obviously the c++11 compiler flags are missing (probably that's an issue with the mkoctfile version distributed with Octave 4.2.0, but I should be able to fix that on the pure-octave side, too). Let's put this merge request on hold until I have this sorted out. Thanks.

[agraef]

I don't understand this, pure-octave 0.8 builds just fine against Octave 4.2.0 if I compile it straight from the source. It only fails with the Portfile. Maybe some snafu in the Pure portgroup, I'm checking that now.

[Schamschula]

Indeed, port groups can be quite an issue: e.g. the octave port group...

[agraef]

It must be the Pure portgroup; here's the compile command when I compile straight from source using just make:

mkoctfile -v "-DOCTAVE_3_8_PLUS -DOCTAVE_4_2_PLUS" -o embed.o -c embed.cc
/usr/bin/clang++ -std=gnu++11 -c -I/opt/local/include -fPIC -I/opt/local/include/octave-4.2.0/octave/.. -I/opt/local/include/octave-4.2.0/octave -I/opt/local/include  -D_THREAD_SAFE -pthread -pipe -Os -stdlib=libc++ -arch x86_64    -DOCTAVE_3_8_PLUS -DOCTAVE_4_2_PLUS embed.cc -o embed.o

Here's the same command when running sudo port -v install:

mkoctfile -v "-DOCTAVE_3_8_PLUS -DOCTAVE_4_2_PLUS" -o embed.o -c embed.cc
/usr/bin/clang++ -c -I/opt/local/include -fPIC -I/opt/local/include/octave-4.2.0/octave/.. -I/opt/local/include/octave-4.2.0/octave -I/opt/local/include  -D_THREAD_SAFE -pthread -Os -stdlib=libc++ -arch x86_64    -DOCTAVE_3_8_PLUS -DOCTAVE_4_2_PLUS embed.cc -o embed.o

Note that the -std=gnu++11 is suspiciously absent there, so it seems that the portgroup specifically edits that option out. Probably that was done to deal with some C++11 issues on really ancient macOS versions in the Tiger ballpark, so I'll have to figure out which variable that is and override it in this specific port.

[Schamschula]

Yup. It seems the pure port group overwrites the libc++11 used by octave.

[agraef]

You found that much quicker than I did. ;-) Where's that portgroup file again??

[agraef]

Found it, it's in https://github.com/macports/macports-ports/blob/master/_resources/port1.0/group/pure-1.0.tcl.

[agraef]

Ok, looks like I have to add this line to the portfile:

configure.cxxflags-append       -std=gnu++11

Let me quickly amend the pull request and rebase, then everything should be good.

[agraef]

Fixed and squashed to a single commit again. Builds fine with Octave 4.2 now, too, so I'd say that it's good to go.

[ryandesign]

Yup. It seems the pure port group overwrites the libc++11 used by octave.

The pure portgroup sets -stdlib to the correct value according to the macports configure.cxx_stdlib variable.

[agraef]

The pure portgroup sets -stdlib to the correct value according to the macports configure.cxx_stdlib variable.

Ok, so the proper way to handle this situation would be to set configure.cxx_stdlib instead of configure.cxxflags-append in the pure-octave Portfile?

[ryandesign]

I don't know. Why does this port need to use a different C++ standard library than the one MacPorts wants to use?

[mojca]

Octave probably achieves the same effect with PortGroup cxx11 1.1 (blind guess). The reason is that Octave requires C++11 (and cannot use libc++ due to other incompatibilities with dependencies). You should probably try to mimic what octave does if you need compatibility.

But the pure PortGroup probably needs a fix in any case. (I would say that we need a variable that tells what the default stdlib setting is. At the moment one can change configure.cxx_stdlib manually and then any logic like if {${configure.cxx_stdlib} ...} is bound to break.)

[ryandesign]

Octave probably achieves the same effect with PortGroup cxx11 1.1 (blind guess). The reason is that Octave requires C++11 (and cannot use libc++ due to other incompatibilities with dependencies). You should probably try to mimic what octave does if you need compatibility.

That's probably true.

But the pure PortGroup probably needs a fix in any case. (I would say that we need a variable that tells what the default stdlib setting is.

Why would need such a variable?

At the moment one can change configure.cxx_stdlib manually and then any logic like if {${configure.cxx_stdlib} ...} is bound to break.)

Why would it break, rather than doing exactly what it was programmed to do?

[mojca]

I would say that we need a variable that tells what the default stdlib setting is.

Why would need such a variable?

(Let's work under assumption that the GCC magic by Marcus doesn't work and that users need to use either libstdc++ v.2 or libc++, that is: forget about GCC for the sake of this argument.)

Scenario A: port needs C++11, but doesn't have any dependencies. So it simply uses

configure.cxx_stdlib libc++

on a no-matter-what basis.

Scenario B: port has some heavy dependencies like boost and needs C++11. In that case the only reasonable thing is

if {${configure.cxx_stdlib} != "libc++"} {
    ui_error ...
}

since one cannot use either of the two stdlibs to compile. But the second example really wants make sure that ${configure.cxx_stdlib} is set to libc++ by default.

Now imagine a PortGroup for compiling software that's all C++11 (think of Qt for example). Imagine scenario A in particular. A PortGroup for more-or-less-standalone software could easily set

configure.cxx_stdlib libc++

to achieve C++11 compatibility.

But then another port with more dependencies (some of which include C++ interface that has been compiled against libstdc++ 2) wants to use the PortGroup. The Portfile has no way to know whether it should break (because those other dependencies have been compiled against libstdc++ and there's no way we could build the port) or if the build should proceed. That is: the port doesn't know whether libc++ has been set globally or by some PortGroup. Usually the logic would be:

if libc++ is default:
    proceed and use libc++
else:
    break, there's no way we could build this port
    (some dependencies use libc++, some use libstdc++)

[agraef]

Why does this port need to use a different C++ standard library than the one MacPorts wants to use?

This is a rather peculiar case, because unlike all the other Pure addon modules, which get built using the system C/C++ compiler directly, pure-octave gets built using Octave's mkoctfile utility.

The sources of pure-octave itself don't need the gnu++11 option in any way, and until the most recent Octave 4.0.3, Octave didn't need it either. Since the recently released Octave 4.2, however, the Octave header files apparently need some GNU-specific C++11 features, and therefore mkoctfile uses /usr/bin/clang++ -std=gnu++11 as its default C++ compiler now. Unless CXX is defined in the environment (which the pure port group does), in which case it will use whatever CXX says, even though it may break the compilation (which it did in this case).

You can check that yourself by trying to compile pure-octave directly from source (with both the latest octave and pure installed). Just make will work fine, but make CXX=/usr/bin/clang++ will give exactly the same errors that I saw before adding the configure.cxxflags-append setting.

So it's not really anything with the pure-octave port itself, and the pure port group is all right, too. It's just that peculiar requirement of Octave 4.2's mkoctfile which simply needs the -std=gnu++11 flag and will bark if it gets overridden by defining CXX. Consequently, I'd say that the way I resolved this now, by just adding that option to configure.cxxflags-append to enforce it, is the Right Thing(TM) in this specific case.

As an aside, I must say that I'm not happy with the Octave 4.2 release anyway. While Octave 4.0 was really stable, 4.2 seems like an interim release to me, with some of the internal APIs being redesigned but not quite there yet. This release is giving me headache also on Linux, since it breaks the internal API which allows modules like pure-octave to embed the Octave interpreter in other C/C++ programs. More precisely, one of Octave's crucial interface routines in that API, eval_string(), just segfaults, probably due to some missing initialization in the API routine that creates the embedded Octave interpreter. This routine works fine in both Octave 4.0.x and Octave 4.3, but it's just completely broken in Octave 4.2. I haven't been able to track this down yet, and knowing that it's fixed somehow in Octave 4.3, I won't waste any more time with this release. So I'm currently using either Octave 4.0.3 or 4.3 instead, on all platforms, and I'm waiting as fast as I can for the upcoming 4.4 release, so that I can just pretend that Octave 4.2 ever existed. 😉

TL;DR Let's just keep everything as it is now, the port builds fine now, the pure port group doesn't need any fixes either, and everyone is happy. 😄

[agraef]

BTW, in case the MP Octave maintainer is listening, can the octave-devel port please be updated so that it builds Octave 4.3, instead of some pre-release snapshot of 4.2? Just an idea...