Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
4.7.3
-
None
-
Windows XP
Description
When creating an extra compiler in the commands there is typically something that uses the input (a file) and produces an output (a file, too).
Many windows shell executables (copy, move, del) can not handle names like: c:/temp/foo.abc but need c:\temp\foo.abc (note the difference between unix style dir separator '/' and the windows style dir separator '\')
The first parameter of the .commands element is converted to a native file name but the parameters are not.
It is clear, that it is difficult to guess if the space separated command parameters are switches (e.g. /foo) or path names (e.g. ./foo.abc).
But the qmake .pro-file line:
win32:preprocesssvnrev.commands = $${PWD}/update_svn_revision.bat $${PWD} $${PWD}/${QMAKE_FILE_IN} $${PWD}/${QMAKE_FILE_BASE}
results in the command
d:\CCNS5\src\optimization\update_svn_revision.bat D:/CCNS5/src/optimization D:/CCNS5/src/optimization/..\..\..\CCNS5\src\optimization\windows_version_revision.rc.SubWCRev D:/CCNS5/src/optimization/windows_version_revision.rc
As you can see the '/' of the first element of the commands is converted to native seperators
but
$${PWD}
is not ....
I think it should be easiest to put the conditional conversion into the hands of the pro-file writer.
How a about an qmake function: fixPathToLocalOS(path) like you have internally as
Option::fixPathToLocalOS
In addition qmake since 4.7.x warns about deprecated '\' ....