Fri 24 Jan 2014 05:47:33 PM UTC, comment #16:
I fixed the segfault with myfeval.c in this changeset (http://hg.savannah.gnu.org/hgweb/octave/rev/d1e16bdb3958). I was just trying to cast away the 'const' attribute and I had accidentally changed the type which was leading to the segfault.
I made a few more modifications to the documentation, but everything looks fine now so I'm going to close this report.
|
Fri 24 Jan 2014 02:29:43 PM UTC, comment #15:
Rik: only when running from inside of Octave, but these can be run from Forge package configure scripts or Makefiles.
Thanks for cleaning that substitution code up. Here are the differences between the old and new that I see now with this change. These are probably good changes, just noting the slight differences now in case it does affect somebody.
So in other words, octave-config now keeps PREFIX to the compiled-in directory, it used to substitute OCTAVE_HOME into the PREFIX variable as well. And mkoctfile now prints the value of PREFIX when OCTAVE_HOME is requested but it is not in the environment.
|
Fri 24 Jan 2014 08:44:50 AM UTC, comment #14:
I checked in the following change so that main.in.cc, mkoctfile.in.cc, and octave-config.in.cc will all use the same functions for setting and substituting OCTAVE_HOME:
http://hg.savannah.gnu.org/hgweb/octave/rev/f1ee47866e6b
It works for me on my Debian system but I didn't test on Windows yet.
|
Fri 24 Jan 2014 08:43:30 AM UTC, comment #13:
I checked in the following change to make the list of variables the same in mkoctfile.m and mkoctfile.in.cc:
http://hg.savannah.gnu.org/hgweb/octave/rev/d9f706dd78df
|
Fri 24 Jan 2014 07:16:36 AM UTC, comment #12:
The attached patch makes myfeval.c work for me.
(file #30359)
|
Fri 24 Jan 2014 06:21:35 AM UTC, comment #11:
Shouldn't OCTAVE_HOME always be defined? From within octave itself
which is accurate.
|
Fri 24 Jan 2014 06:15:20 AM UTC, comment #10:
I see that the file mkoctfile.m has a different list of flags for the -p print option than the mkoctfile executable. Try
versus
from the command line.
|
Fri 24 Jan 2014 06:12:05 AM UTC, comment #9:
I compiled all of the sample pieces of code in the examples directory with the new mkoctfile. I found a lot of out-of-date material in the documentation which I fixed here (http://hg.savannah.gnu.org/hgweb/octave/rev/adb7c7e6a4a1).
One major problem I found was that myfeval.c leads to a segfault.
It might be some new problem with my machine because I tried it with past versions of Octave (3.6.4, 3.4.3, 3.2.4) and I also got a segfault.
|
Fri 24 Jan 2014 05:55:49 AM UTC, comment #8:
I compared the values of all of the variables for mkoctfile -p and octave-config -p against the shell scripts, with and without OCTAVE_HOME defined. I pushed a fix for octave-config that was stripping PREFIX when OCTAVE_HOME was not defined.
http://hg.savannah.gnu.org/hgweb/octave/rev/159ddd7ce1b3
|
Thu 23 Jan 2014 09:49:48 PM UTC, comment #7:
I updated the .cc file versions. I think they are consistent with the script versions now. I wouldn't be surprised to find a few problems in the future, but I think these should work.
http://hg.savannah.gnu.org/hgweb/octave/rev/50505bf88b82
|
Thu 23 Jan 2014 06:02:06 PM UTC, comment #6:
I just did a small test and the help output is different between the executable and the script file. The script file mentions '-pthread' as an option.
|
Thu 23 Jan 2014 05:43:02 PM UTC, comment #5:
Thanks for committing that, I didn't have time to take care of it yesterday. Test time was mostly my reason for suggesting gui-release, but this will be great to get into the next stable release.
|
Thu 23 Jan 2014 04:30:47 PM UTC, comment #4:
I pushed Mike's changeset to the stable branch here (http://hg.savannah.gnu.org/hgweb/octave/rev/ee7f66925267) so that it can be a part of 3.8.1. It's ready for test/comparison with the existing script version.
|
Wed 22 Jan 2014 08:01:46 PM UTC, comment #3:
I'll compare the two versions of mkoctfile and octave-config. You can go ahead and commit the change and then I'll compare the new C++ versions with the last sh versions.
|
Wed 22 Jan 2014 05:30:52 PM UTC, comment #2:
Should the fix happen on the stable branch? Even though this is a relatively big change it sort of seems like it has to happen if mkoctfile is going to work on cygwin.
There are a number of other reports about mkoctfile which would probably be easier to solve if we had just a single source file. In particular, we probably should pass on unrecognized flags directly to the compiler (see bug #34169).
Is anyone volunteering to do the consistency checking between the compiled and script versions before we get rid of the script version?
|
Wed 22 Jan 2014 05:47:34 AM UTC, comment #1:
Yes, it has been discussed several times in the past. One of the reasons for not doing it was that it was easier for users to tweak a shell script instead of a compiled program. By that logic, then maybe all of Octave should be a shell script. :-)
I was reminded of (and annoyed by) this issue again today when I was thinking of making some changes to mkoctfile. It's annoying to have to make changes twice, and difficult to ensure that the programs don't diverge from one another. While I was working on mkoctfile, I noticed some differences between the shell script and the C++ program.
So you can count me as in favor of the change.
|
Wed 22 Jan 2014 03:41:34 AM UTC, original submission:
I am pretty sure this has been brought up before but not yet addressed. I would like to modify the src directory to build mkoctfile and octave-config as executables unconditionally. We currently have to maintain two independent implementations for these programs, simply because we can do shell scripts on Unixy systems but not on Windows. If we have to do executables on Windows, then we might as well only maintain the C++ implementations.
This is related to bug #41249, the mkoctfile and pkg commands are currently broken for 3.8.0 on cygwin.
Attached changeset removes the conditional and builds the mkoctfile and octave-config executables on all systems. Works for me on Debian. I made this on the default branch, but I think this change should be suitable for gui-release, let me know what you think.
I have to note that I have not gone through all of the options and variables in these programs to ensure that they match up perfectly between the two implementations.
|