Thu 20 Jul 2017 12:12:09 PM UTC, comment #12:
yep - package now builds under windows octave 4.2.1 and 4.3.0+
|
Thu 20 Jul 2017 09:41:58 AM UTC, comment #11:
Currently no effort is made to make building the extra docs work under Windows or while cross-building. The extra docs should be pre-built natively. This is also noted in a comment at the top of src/Makefile.in.
I checked in a patch which fixes pre-building the extra docs with the release: target of the toplevel Makefile. Is that enough for your needs?
|
Wed 19 Jul 2017 05:48:02 PM UTC, comment #10:
Which reminds me that in mxe-octave, in order to get it to cross compile, I assigned in the Makefile:
BUILD_CXX ?= gcc
and for the CXX in the doc rule to BUILD_CXX
|
Wed 19 Jul 2017 05:43:39 PM UTC, comment #9:
I guess should be a new bug report, but attempting to compile under windows (using latest from the repo)
Trying to run the pq_update_types.bin file afterwards gives same
'Bad file number' error
|
Tue 18 Jul 2017 07:06:36 PM UTC, comment #8:
A fix is pushed, including a general frame to deal with simple symbol changes. I suggest to use this frame for similar cases, it'll be published at the OF website.
Deprecated symbols don't seem to be available long enough for my previous strategy to work.
As for filing bugs for build failures with dev, I can't suggest a general rule. In the packages which I maintain I think I would fix these even without reports, but in some cases not before dev is about to become the next major release. But your build fixes against dev for many packages are doubtless really useful.
On the other hand, maybe a development strategy for the Windows build could be devised in which you have more time to wait for (or produce...) build fixes of packages against dev ...? It's only because package development normally doesn't immediately parallel each change in Octave dev, except on Windows.
|
Wed 12 Jul 2017 02:39:25 PM UTC, comment #7:
I guess the question is really, should we post build failures of packages against dev as bugs?
In the mean time, I have a fix for building/testing
|
Wed 12 Jul 2017 02:37:00 PM UTC, comment #6:
But it was with Octaves development version, which AFAIK is not near a release. So I'm not sure that I should take this failure as the trigger to switch from deprecated to modern.
|
Wed 12 Jul 2017 02:29:37 PM UTC, comment #5:
In this case, it was more than just a depreciated symbol - it wont compile. It does print out a number of other messages about depreciated functions as well - I was ignoring them
|
Wed 12 Jul 2017 12:54:29 PM UTC, comment #4:
I didn't see your patch, it crossed with my last post. However, my current strategy with deprecated symbols in Octave is to use the deprecated ones as long as they are supported and then to unconditionally switch to the replacements. This spares testing for each single deprecated symbol and should (?) still provide compatibility with a certain range of Octave versions.
|
Wed 12 Jul 2017 12:44:17 PM UTC, comment #3:
Probally not - just for testing mxe-octave with dev octave.
|
Wed 12 Jul 2017 12:28:40 PM UTC, comment #2:
I tend to adapt to Octaves API changes in the development branch only in greater chunks, preferably after some re-structuring of Octave is finished. Do you need this fixed already now for some reason?
|
Wed 12 Jul 2017 12:25:30 PM UTC, comment #1:
Patch checking for mach_info
(file #41190)
|
Wed 12 Jul 2017 12:19:05 PM UTC, original submission:
With recent changes in name spaces in octave:
|