Conversation
mcg1969
force-pushed
the
rebuild-ci
branch
4 times, most recently
from
af32e78 to
77197be
Compare
mcg1969
force-pushed
the
rebuild-ci
branch
7 times, most recently
from
bc05efd to
c642ba9
Compare
|
@siko1056 for Linux, I tried using the ubuntu-20.04 image to build the MEX files to get an older octave to compile against. The result is that it building against apt-installed Octave 5.2 The tests use ubuntu-22.04, as follow:
For some reason, the snapd test is failing when I do that. So I think I'm going to switch to ubuntu-22.04 for building to see if that resolves it. |
|
Nope, building with ubuntu-22.04 did not help. Given your existing tests, it would seem to be necessary to rebuild the mex files altogether for snapd Octave. |
|
I've been doing some digging and found that this is the error that prevents the precompiled mex files to work on snap: If I recompile the mex files using snap octave, however, they work fine... and they work fine on apt octave as well. This is likely due to forward compatibility issues. |
mcg1969
force-pushed
the
rebuild-ci
branch
5 times, most recently
from
54531ea to
9fe52a9
Compare
|
OK, we're looking good. Building with snap provides enough forward compatibility for apt and flatpak. |
1 participant
Now that we can reliably install Matlab and Octave on all four key platforms, we can build the MEX files using CI.
This reworked CI process works as follows:
First, it builds MEX files for each of four platforms (linux, macos intel, macos arm, windows) for MATLAB and Octave. It uses an older OS version, and the oldest MATLAB version possible, to maximize the chance of forward compatibility. It's not obvious how to select an older version of Octave, unfortunately.
Second, it builds ZIP and TGZ bundles containing the source code plus all of the compiled MEX files.
It then runs a functional test of those bundles on the latest versions of each OS, and MATLAB. This helps ensure that forward compatibility has been preserved, and that the bundle is complete.
@siko1056 I have implemented an equivalent CI strategy for SDPT3. Obviously, it's generally not good practice to have binaries in a source repo. But until now, we didn't really have an alternative, because we could not reliably build the MEX files in CI. This new approach allows us to do that.
Note that we lose 32-bin Linux and Windows with this, but at this point, that seems reasonable. But what we could do is restore just those platforms to the repo and indicate they are use at your own risk. I have no idea if anyone would even be trying to use them now!