"not recognized as an internal or external command, operable program or batch file"

[ComServant]

I'm unable to compile, because I keep getting this compile message: (This is with a clean install of the QtSDK)


18:46:10: Running build steps for project GameClient...
18:46:10: Configuration unchanged, skipping qmake step.
18:46:10: Starting: "C:\mingw\bin\mingw32-make.exe"
C:/mingw/bin/mingw32-make.exe -f Makefile.Debug
mingw32-make.exe[1]: Entering directory `D:/Jamin/(Programming)/(Projects)/(AdventureFar)/GameClient/(Game)/Code/Build-windows-x32-debug'
g++ -c -g -pg -O0 -std=c++0x -fstrict-aliasing -Wstrict-aliasing -frtti -fexceptions -mthreads -Wall -DUNICODE -DQT_LARGEFILE_SUPPORT -DQT_DLL -DQT_GUI_LIB -DQT_CORE_LIB -DQT_HAVE_MMX -DQT_HAVE_3DNOW -DQT_HAVE_SSE -DQT_HAVE_MMXEXT -DQT_HAVE_SSE2 -DQT_THREAD_SUPPORT -DQT_NEEDS_QMAIN -I"c:\QtSDK\Desktop\Qt\4.8.1\mingw\include\QtCore" -I"c:\QtSDK\Desktop\Qt\4.8.1\mingw\include\QtGui" -I"c:\QtSDK\Desktop\Qt\4.8.1\mingw\include" -I"d:\Jamin\(Programming)\(Libraries)\[MinGW]\Includes" -I"c:\QtSDK\Desktop\Qt\4.8.1\mingw\include\ActiveQt" -I"debug" -I"..\GameClient" -I"." -I"c:\QtSDK\Desktop\Qt\4.8.1\mingw\mkspecs\win32-g++" -o debug\Time.o ..\GameClient\Common\Types\Time.cpp
mingw32-make.exe[1]: Leaving directory `D:/Jamin/(Programming)/(Projects)/(AdventureFar)/GameClient/(Game)/Code/Build-windows-x32-debug'
'D:\Jamin\' is not recognized as an internal or external command,
operable program or batch file.
mingw32-make.exe[1]: *** [debug/Time.o] Error 1
mingw32-make.exe: *** [debug] Error 2
18:46:11: The process "C:\mingw\bin\mingw32-make.exe" exited with code 2.
Error while building project GameClient (target: Desktop)
When executing build step 'Make'

Why does it say:
'D:\Jamin\' is not recognized as an internal or external command, operable program or batch file?

Because the D:/ drive is a network drive (but I'm compiling locally!), I was previously getting alot of:
"UNC paths aren't allowed!" messages, because "D:/Jamin/...etc.../" would keep get translated to: "//NETWORKED/D/Jamin/...etc.../", against my will.

It's still a network drive, if that matters. I just manually editted GameClient.pro.user and 'Find & Replace'd the beginning of the path (after first trying a symbolic link - which didn't work).

What is going on? How can I fix this?

I'm using Windows 7 32bit, with a clean install of QtSDK 4.8.1 (which means QtCreator 2.4.1), and I'm using a MinGW 4.6.3, installed to "C:/MinGW/bin".

[ChrisW67]

So, you are using your own tool chain and your own version of Qt compiled with it. Nothing really to do with the Qt SDK.

Does it change if the files are really local?
Does it change if you use the supported MingW and matching Qt in the Qt SDK?
Does it change if you replace backslashes '\' with forward slashes '/' in the PRO file paths?

Do you really have directory structure where folder names are in parentheses or square brackets? If you intend moving this to Mac or Linux then you will probably want to rethink that as these characters have special meaning to the command shell. It may even be the issue here given GNU make's UNIX pedigree (What shell will it be using?). The only place in the command you show where "d:\Jamin\" is present is immediately followed by one of your parenthetical directories.

[ComServant]

So, you are using your own tool chain and your own version of Qt compiled with it. Nothing really to do with the Qt SDK.
I'm using the version of the Qt API that came with the SDK, I didn't recompile it.


Does it change if the files are really local?
The files really are local! =(
They are on a networked drive, but the drive is actually on the development machine I'm using. I think, because it's networked, Windows itself keeps making the path UNC instead of regular. When browsing in Windows explorer, the path shows at UNC even.


Does it change if you use the supported MingW and matching Qt in the Qt SDK?
I'll check.


Does it change if you replace backslashes '\' with forward slashes '/' in the PRO file paths?
All of them are, as far as I can tell.


Do you really have directory structure where folder names are in parentheses or square brackets?
Yeah, I use them to make my more common and static folders at the top of Windows Explorer (since brackets are sorted alphabetically before letters).


If you intend moving this to Mac or Linux then you will probably want to rethink that as these characters have special meaning to the command shell. It may even be the issue here given GNU make's UNIX pedigree (What shell will it be using?). The only place in the command you show where "d:\Jamin\" is present is immediately followed by one of your parenthetical directories.
I do intend on compiling on Mac and Linux - thanks for the heads up, I didn't know brackets and parentheses would be a problem. I'll try without them.

[ComServant]

Here's what I've done now:
- Disabled the network sharing of the drive until I get this fixed.
- Relocated the project to a new folder, with no parentheses, spaces, or other symbols ("D:\Game\Code\GameClient").

I can't compile using the default installation of the QtSDK, because my project uses C++11 features not in the version of MinGW QtSDK includes (it includes MinGW 4.4, my project requires 4.6).
However, I can create a test project using Qt and compile just fine with the default compiler or with my additional compiler.

The previous errors I was getting are no longer appearing, but when compiling my actual project, other errors are popping up.
It appears the problem is that the Qt libraries weren't compiled with the same version of MinGW that my project is being compiled with, and so errors result.
Which is odd, since previously I was using 4.6.2 with Qt 4.7... Researching the issue, I think this is probably because of the different between SJLJ and Dw2 builds of MinGW.
*sigh* Well, I'm going to take a crack at compiling Qt from source. Thanks for the help.

[wysota]

To work around your path problems, you can probably make a soft link (not a shortcut!) that will point to the weird path. Since the link is done on the filesystem level, Windows shouldn't mess with it.