Wed 09 Oct 2013 01:10:28 AM UTC, comment #11:
Done, closing as requested.
http://hg.savannah.gnu.org/hgweb/octave/rev/6b8df90c8806
When you open the other bug, I already have a comment that the configure failure you are seeing in the windows package fails for me on Linux as well.
|
Tue 08 Oct 2013 08:56:52 PM UTC, comment #10:
Using your patch, packages communications, control, general, image, io, linear-algebra, miscellaneous, optim, signal, specfun. statistics and struct install fine.
After you pushed, please close this bug. I'll open another one then for the failing windows package installation.
|
Tue 08 Oct 2013 02:05:09 PM UTC, comment #9:
I already tried patches that are essentially the same. They allow me to install various packages on windows (e.g., general, struct, miscellaneous, statistics, control, io, etc.), and an individual mkoctfile call works a well, so I assume blindly that this changeset will work too. I'd say: just push.
Thank you John and you for fixing this.
But the remaining problem is installation of the windows package. I first thought it might be related to the classdef branch, but it won't install with a recent "default" branch build either.
The window package installed OK (on MXE builds) until shortly before the __hook cs (I just saw it was patch tracker #8177), so I (just) suspect there's a link.
Tonight I'll scutinize in more detail the changelog, for a clue in other changesets since the last build that allowed the windows pkg to install fine.
|
Tue 08 Oct 2013 11:44:56 AM UTC, comment #8:
Try the attached changeset please. If you could please try testing a package install as well as a call to the mkoctfile function on a single .cc file for example.
(file #29325)
|
Sun 06 Oct 2013 08:36:36 PM UTC, comment #7:
Trying in the CLI didn't get me much further w.r.t. the windows package installation issue.
I could only assess that the newlines in the 'cmd' variable (created in Ls 66-67 of configure_make.m) are actually CRLF sequences (I guess that's why the contents of variable 'cmd' looked garbled).
Hopefully next Tuesday I'll have time to look into this again.
|
Sun 06 Oct 2013 07:49:59 PM UTC, comment #6:
The variable 'octave_binary' also needs an .exe extension as _gripe_missing_component_ checks this executable as well, a few lines lower.
With the patch from comment #2, after fixing this, dropping the "if then else" for the superfluous '.' and trying again, the build_packages script in the MXE Windows build works again- for most packages, see below.
Shall I try to produce a changeset later (I'm on Windows now, I usually cross-build on Linux), or will you, Mike?
However, it turns out that now the windows package doesn't install anymore (it did fine before changeset 17516:21656a949661).
I tried to debug this but didn't get very far; the error messages are:
The above compile errors are a red herring. The actual error is with the configure command.
I got only as far as assessing that the variable 'cmd' cooked up in lines 66-67 of ..../pkg/private/configure_make.m seems to contain a number of newlines inserted at the end (clearly distinguishable from line wrap):
Discerning where these newlines come from proved undoable for me; a stumbling block I hit (while stepping through configure_make) was that this 'cmd' variable was garbled at the end in my Octave GUI terminal (maybe a separate issue).
(The windows pkg install issue is reported here because I suppose it is related to changeset 17516:21656a949661)
|
Sat 05 Oct 2013 12:33:53 AM UTC, comment #5:
Oh, yeah, I guess it does include the ".". In that case it is even easier to fix.
|
Fri 04 Oct 2013 10:42:27 PM UTC, comment #4:
Thanks for whipping out that patch so fast.
The mkoctfile.m function needs the same fix as well.
I haven't tested (I can't test actually) but isn't the extra "." redundant? IIRC EXEEXT is ".exe" on windows, not just "exe".
|
Fri 04 Oct 2013 10:27:42 PM UTC, comment #3:
Another thing is that I think we should only have one version of these files. If we have to use compiled programs on some systems, then we should probably use compiled programs on all systems to avoid duplication. It's kind of a maintenance hassle to have to modify two programs when you want to make a change.
|
Fri 04 Oct 2013 10:25:40 PM UTC, comment #2:
How about something like the attached change? I don't think you have to look for both. EXEEXT is only set on systems like Windows, and Windows uses the compiled versions.
(file #29297)
|
Fri 04 Oct 2013 10:14:59 PM UTC, comment #1:
Yeah, apologies, I'll work on a patch for this as soon as I can.
The right way to check the executable extension is with
For mkoctfile and octave-config, I suppose it should check for both, the name with and without EXEEXT, since they both exist as either shell scripts or compiled programs.
|
Fri 04 Oct 2013 08:44:07 PM UTC, original submission:
(Not sure whether this is "configuration and build system" or "Octave function")
changeset 17516:21656a949661 (containing patches for missing Octave components) introduced a number of adaptations for finding executables like mkoctfile, octave_config_info etc.
Now, in a typical section in ./scripts/.../pkg/private/configure_make:
:
octave_bindir = octave_config_info ("bindir");
ver = version ();
mkoctfile_program = fullfile (octave_bindir, sprintf ("mkoctfile-%s", ver));
octave_config_program = fullfile (octave_bindir, sprintf ("octave-config-%s", ver));
octave_binary = fullfile (octave_bindir, sprintf ("octave-%s", ver));
:
<snip>
:
if (! exist (mkoctfile_program, "file"))
_gripe_missing_component_ ("pkg", "mkoctfile");
...the if (! exist.....) clause is false because on Windows mkoctfile, octave and octave_config_info executables have .exe file name extensions. This isn't honoured in the stanzas higher up where the full paths to these files are constructed.
This also happens in mkoctfile.m and many other files.
I have no idea how and where to easily handle this. Use the "ispc" function and if true, pad ".exe" after the fullfile statements? Would that work on MXE cross-builds?
Anyway this changeset effectively blocks building binary octave-forge packages, and invoking mkoctfile.
|