Sat 12 Nov 2016 12:04:36 AM UTC, comment #12:
I think we could talk about what the right solution for a future release of Octave could be. I know this was touched on at least a bit when we made the move to deprecate octave_config_info. There are certain feature tests that some Forge packages need to perform in their configure scripts.
The image package needs to run a native octave process to query whether the "im2double" function is implemented in Octave itself, so that it can either provide its own implementation or not. This kind of thing is a temporary measure until it can do a hard dependency on the Octave 4.2 release for example.
The communications package runs a native octave to query the options that Octave has for building against HDF5 (HDF5_CPPFLAGS, LDFLAGS, etc), which are not available via a cross-mkoctfile tool. This could be done differently, by querying for HDF5 itself rather than relying on Octave for how to (and whether or not to) build against HDF5.
|
Fri 11 Nov 2016 09:50:03 PM UTC, comment #11:
Also, is it really necessary? Is there no way around this for the individual packages that currently require it? I admit that I haven't tried to look at the problem.
|
Fri 11 Nov 2016 09:49:10 PM UTC, comment #10:
Hmm, good question. For my purposes, it would just be useful to have the build-octave target to allow building packages when cross compiling and I would be able to ensure that the dependencies for that are present.
For now, I guess it doesn't matter. I can build my own before creating the windows binaries that we distribute.
|
Fri 11 Nov 2016 09:28:46 PM UTC, comment #9:
in some ways it makes sense to have a build-octave - although then do we also need build-xxxx for all the octave dependencies as well?
|
Fri 11 Nov 2016 09:04:20 PM UTC, comment #8:
I can always install a copy of the current Octave before beginning to build the binary distribution for Windows, but why not just have a "build-octave" package that builds it for us and installs it in the mxe "usr" directory tree, same as the other build tools? Then we can ensure that we have the proper version available. If you agree, I can add the package. But yes, we can also close this report.
|
Fri 11 Nov 2016 08:31:16 PM UTC, comment #7:
Can we call this fixed now?
|
Mon 07 Nov 2016 07:56:25 PM UTC, comment #6:
I had a patch in mxe-octave to ignore that issue, however it should work ok if we assume that a current native octave is installed.
|
Mon 07 Nov 2016 12:42:39 PM UTC, comment #5:
I think the mapping pkg build has similar issues in mxe (rad2deg and deg2rad functions). Carnë's configure script didn't work there either.
|
Thu 03 Nov 2016 04:54:57 PM UTC, comment #4:
And check and warn in cross build if don't have the correct version of octave
http://hg.octave.org/mxe-octave/rev/724749afb8b5
|
Thu 03 Nov 2016 04:36:26 PM UTC, comment #3:
Pushed to mxe this change to fail pkg build if configure failed:
http://hg.octave.org/mxe-octave/rev/bdcbb82d57e2
|
Thu 03 Nov 2016 11:59:33 AM UTC, comment #2:
There was a discussion on the maintainers list (I think) where it was decided it was resonalable to expect whoever was packaging the binary packages would have a native octave installed.
Having said that, currently mxe doesn't check that a native veersion is installed, and I see from doing a build myself, that mxe silently fails on the configure script if you don't have octave and packages just the install the inst files
So perhaps a check for octave and at the very least a warning given during the mxe build would be good.
Theres at least one other package in mxe that would check the octave version, however I think I patched it in mxe to just not install the file make would conditionally not install.
|
Wed 02 Nov 2016 06:02:24 PM UTC, comment #1:
This works for me. I believe you are using the mxe octave releases and I thought there was already a bug for this but apparently not.
The issue is that during package installation, the image package checks if the function im2double already exists. If it does not, then it creates that function. I'm unsure what mxe is doing when running configure but I guess during that phase, it runs an older Octave version without im2double instead of the one that it just built.
I'm unsure if this is an issue with the image package (and there's at least the mapping package with a similar approach) or with mxe-Octave. Can anyone working on mxe comment?
|
Tue 01 Nov 2016 11:53:28 AM UTC, original submission:
|