Support 3rd-party apps that build against Octave

[apjanke]

There are some 3rd-party applications and libraries that need to be built against Octave. This is probably mostly in the form of MEX or OCT file bindings for Octave. An example is Dynare, an economic modeling application that has Matlab/Octave bindings.

Code built against Octave needs to be linked against the exact installation location of Octave (unlike Matlab MEX files, which are portable in that regard). So if you want to use one of these built-against-octave applications with Octave.app, it needs to be built against your Octave.app specifically. And that includes being built against all the libs in Octave.app's bundled Homebrewed userland; you can't build them against your main Homebrew installation.

Let's consider adding support for this in Octave.app.

This will be nontrivial, because it basically means setting up Octave.app as a full Unix build environment for programs to be built against.

What we do for things like Octave Forge packages that have library dependencies is to just unconditionally build them into the main Octave.app build. I don't think that's the right approach here, though: I don't want to end up pulling in everything under the sun that has Octave bindings. And then you're stuck with a fixed version. And developers of those packages won't be able to do development of them using Octave.app.

Questions

1. Is this even a good idea?
2. Do we want to spend the time doing it?
3. How will it work? What mechanisms will we provide for setting up the build environment?
4. Where should the compiled packages live on disk?

Requirements

1. Must not require advanced sysadmin activity on the part of the user. E.g. something that requires disabling macOS's System Integrity Protection to create an /opt/octave-app directory is a no-go in my view.
2. Must play well with Homebrew and MacPorts installations.

For 2, I mean that our mechanism must not interfere with a system-level Homebrew or MacPorts installation, and it should also work in their presence, with no additional work on the part of the user.

Thoughts

My initial inclination is that the built packages should live under /Library/Application Support/ or ~/Library/Application Support/, in a version-specific Octave.app/<version>/userland directory.

You could just install them into the Homebrewed userland under /Applications/Octave-<ver>.app, including using the brew command from there. But I don't think that's the right approach: macOS app bundles are supposed to be immutable. It would break app signing, if nothing else. (If we ever get app signing working, that is.)

[m0byn]

Would be very nice to have Dynare included in Octave.app. Currently, if one wants to use Dynare with Octave on macOS it is needed to install it via Homebrew. I was able to install everything but then installing the statistics package in Octave such that I can use Dynare with it I did not succeed. If anyone is interested the problem described in more detail can be found here, here and related to that also here.

[apjanke]

Thanks for the input @mzerobin! We're gonna ruminate on this a bit and see if there's anything we can do here.

[mmuetzel]

Code built against Octave needs to be linked against the exact installation location of Octave (unlike Matlab MEX files, which are portable in that regard).

I came across this old and closed bug report: https://savannah.gnu.org/bugs/?53627
You provided a patch there: https://savannah.gnu.org/bugs/download.php?file_id=44700
Afaict, it never made it into the sources upstream. (Maybe because the original issue was solved on GNU/Linux and no new report was opened for macOS.)

Do you think that that change (or a similar one) would allow having "portable" .oct (and .mex) files on macOS?
Would that help for this issue?

[apjanke]

Would that help for this issue?

Oh! I think so? I think that would make it so that OCT and MEX files that were just built against Octave would be "portable" and no longer have this problem. I don't know what it would do for OCT and MEX files that also linked against additional libraries besides Octave; I'm not enough of a linker expert. Maybe it would even fix the whole problem because all their linked libs would be bind-at-load?

[mmuetzel]

I pushed your change to upstream Octave here:
https://hg.savannah.gnu.org/hgweb/octave/rev/b4cb9d04f3cf

I'm not sure how "-bundle_loader" on macOS works though.
Does it point to a binary that provides the symbols only at link time? Or is the resulting library linked somehow to that specific binary at that specific location indefinitely?