Thu 27 Jan 2011 08:25:52 AM UTC, comment #10:
It's possible to fix the ChangeLog entry by committing a new changeset.
I don't know of a way to change the commit message once the changeset has been pushed to a public archive that won't potentially cause trouble. And as far as I know, I don't have the necessary access to savannah to do it myself. I Don't think it matters too much.
|
Thu 27 Jan 2011 07:13:20 AM UTC, comment #9:
Ok, it looks cleaner with the edits.
The only thing I noticed now is that the commit message and scripts/ChangeLog still say that OCTAVE is only exported to configure. But I don't think its worth trying to still change this, even if this should be possible.
|
Wed 26 Jan 2011 08:48:55 PM UTC, comment #8:
I installed your patch with a few edits. I don't see why we shouldn't also export OCTAVE to the Make process. Also, there is no need to say "With a recent Octave version" in the manual, since the manual is documenting the current version of Octave which has this feature. Otherwise, almost all documentation in Octave would have to start with a phrase like that...
http://hg.savannah.gnu.org/hgweb/octave/rev/ad636c1f353b
|
Tue 25 Jan 2011 09:16:04 AM UTC, comment #7:
Another modification, replacing the previous patches: when calling configure, also export OCTAVE (path of running Octave). Also, the previous patch is corrected to use cstrcat instead of strcat when configure is called.
Rationale for exporting OCTAVE in environment to configure: configure might be written using autoconf to generate m-files from templates. Hereby, the involved tests may check for features of Octave with interpreted code and so need to call the correct Octave version.
(file #22507)
|
Fri 21 Jan 2011 12:06:14 PM UTC, comment #6:
Here is a better patch: these variables also exported to potentially called "configure".
(file #22483)
|
Wed 19 Jan 2011 12:31:52 PM UTC, comment #5:
So here is a verified patch, including documentation.
(file #22456)
|
Tue 18 Jan 2011 09:52:06 AM UTC, comment #4:
Then I agree that the pkg function should export MKOCTFILE and perhaps OCTAVE_CONFIG environment variables that are set to the full paths of the mkoctfile and octave-config programs that correspond to the running version of Octave. That at least allows the package Makefiles to use the right versions of these programs.
|
Tue 18 Jan 2011 09:14:52 AM UTC, comment #3:
To answer your question: if I run an Octave version that is not in the PATH (or not the first Octave in the PATH), and install a package, the package is installed at the correct places for the version of Octave I'm running. But if during installation the packages Makefile simply calls "mkoctfile", it runs the first mkoctfile in the PATH, which does not correspond to the version of Octave I'm running.
|
Tue 18 Jan 2011 08:43:53 AM UTC, comment #2:
Suppose you have multiple versions of Octave installed, one in your PATH and one not, and you are running the one that is not. then you use the pkg command to install a package. I think you should install package for the version of Octave that you are running. Does that not happen now? If not, then maybe there is something that should be fixed in the pkg function so that this works as I think most people would expect.
|
Tue 18 Jan 2011 06:41:02 AM UTC, comment #1:
Realized that this rather should be handled by configure scripts, so this bug I submitted is probably invalid. Sorry for the noise.
|
Fri 14 Jan 2011 12:34:17 PM UTC, original submission:
This applies to systems with 2 (or more) different Octave versions installed.
While mkoctfile.m chooses the mkoctfile shell-script matching the Octave version by calling 'fullfile (octave_config_info ("bindir"), sprintf ("mkoctfile-%s", OCTAVE_VERSION))', pkg does not use mkoctfile.m but relies on Makefiles in packages. But there is no clean way to find out which mkoctfile (shell-script) version to call in the packages Makefile.
I suggest that 'pkg install' exports the value of 'fullfile (octave_config_info ("bindir"), sprintf ("mkoctfile-%s", OCTAVE_VERSION))' in an environment variable (say 'mkoctfile') to enable calling the correct mkoctfile version in the Makefile.
|