Windows: incorrect quoting in Makefile generation

[Yuv]

Reported on Hugin-PTX http://groups.google.com/group/hugin-ptx/t/d33b5bc24aada66b

HuginSetup_2010.4.0-64bit_Windows.exe on my Windows 7 x64. Everything work fine, until i try to
create the pano. Then i got the following message:

[...]

===========================================================================
System information
===========================================================================
/usr/bin/sh: -c: line 1: syntax error near unexpected token `(6'
/usr/bin/sh: -c: line 1: `echo Operating System: Windows 7 (6.1 )'
make: *** [info] Error 258

Makefile attached. Obviously lacking quotes in the info target around line 211.

[tmodes (tmodes)]

The quoting is correct. We are using Windows Command Shell on Windows and not bash.
The makefile contains a line which should according to doc of GNU make force to use cmd.exe, but it seems to use a bash shell which is somewhere in the PATH. There is probably a bug in GNU make.
Work around is to remove the path to the bash shell from the PATH variable.

[Marek (gmbh)]

Same for me:

===========================================================================
System information
===========================================================================
/usr/bin/sh: -c: line 1: syntax error near unexpected token `(6'
/usr/bin/sh: -c: line 1: `echo Operating System: Windows 7 (6.1 )'
make: *** [info] Error 258

[tmodes (tmodes)]

Have you tried the proposed solution?
Remove the directory which contains a sh.exe (or maybe bash.exe) from your PATH variable.

[Jean-Jacques Carron (jjcarron)]

I have had the same problem and your solution had solve it.

I just have start a command shell, limit the path to the Windows minimum

set path=C:\Windows\system32

and start Hugin from the bin directory

Thank you for the Tip

[Yuv (yuv)]

would it make sense to use a BAT file to start Hugin instead of starting the actual binary?

that BAT file would do what Jean-Jacques just mentions, i.e. set the path clean and then start the actual Hugin binary.

moreover: can the Hugin binary be prevented from starting if a particular environment variable is not set? if yes, then that BAT script should set a variable environment such as 'set hugin_env=true' and the Hugin binary should start only if hugin_env is set.

This would prevent much of the confusion from conflicting paths.

[Bruno Postle (brunopostle)]

There are lots of good reasons why a user would want to keep their environment, resetting it shouldn't be necessary.

Our assumption is that 'make' is using the wrong shell for some reason, i.e. it is told to use cmd.exe but uses the cygwin sh.exe instead.

Alternatively it could be that Hugin is unintentionally running the cygwin make.exe instead of the shipped win32 make.exe, this would explain why it is incapable of finding cmd.exe.

[Yuv (yuv)]

my understanding is that such a script would only change the environment for Hugin, not the global environment.

I recall from the time I was using Windows that I had two different icons to access the console. one was the standard one, in windows. The other one was installed by MSVC express edition. starting that second icon had completely different environment variables, e.g. a different path.

[tmodes (tmodes)]

> Our assumption is that 'make' is using the wrong shell for some reason,
> i.e. it is told to use cmd.exe but uses the cygwin sh.exe instead.

I tested with different makefile:
First the current implementation used by hugin (SHELL variable quoted for shell):
SHELL="c:/windows/system32/cmd.exe"

all:
 @echo ${SHELL}

make -f test.mk outputs:
SHELL is sh.exe
which is obviously wrong.

Removing the quotes (SHELL=c:/windows/system32/cmd.exe) results in correctly output:
SHELL is c:/windows/system32/cmd.exe

And now a last try with SHELL=c:\windows\system32\cmd.exe (with windows path separators and without quotes) gives the same output.
So gnu make processes the SHELL variable different than others

So I modified the makefile generation to the last variant (commited as efade34da4f6). Hopefully this fixes the issue of selecting the wrong shell.

> Alternatively it could be that Hugin is unintentionally running the
> cygwin make.exe instead of the shipped win32 make.exe, this would
> explain why it is incapable of finding cmd.exe.

This can not be happen. Hugin is always using make.exe in hugins path.

[WFox (sodele-fuchs)]

in my path I have the sh.exe from winavr and i don't want to change the path variable.

When I rename the sh.exe temporarly the makefile works completly correct.