Is there another Win32 function which could be used?
Peter
Currently the Ninja generator in cmake uses cmd.exe
and as usual the command line becomes too long.
Is it good practice to use && in a generated build script?
Peter
On 01.02.2012 22:33, Petr Wolf wrote:
> Hi Peter,
>
> on Windows, you can always use "cmd" as the command, i.e.
>
> rule myrule
> command = cmd /c foo.exe && bar.exe
>
> Hope this helps
>
> Petr
>
From my point of view, the answer is no. That's what stopped me in the
development of the Ninja Generator for CMake. I needed && and I knew
it gonna be a problem on Windows. So, you are back to the questions in
the others threads related to how to make ninja's syntax allow
redirections, working directories, etc...
I think we cannot avoid it.
Regards,
-Nico
> On 01.02.2012 22:33, Petr Wolf wrote:
>>
>> Hi Peter,
>>
>> on Windows, you can always use "cmd" as the command, i.e.
>>
>> rule myrule
>> command = cmd /c foo.exe && bar.exe
>>
>> Hope this helps
>>
>> Petr
>>
>> On 1 February 2012 21:58, Peter Kümmel <synth...@gmx.net
>> <mailto:synth...@gmx.net>> wrote:
>>
>> Currently we use CreateProcess on Windows to start a command.
>> But I assume it is not possible to pass multiple commands
>> concatenated by && to CreateProcess.
>>
>> Is there another Win32 function which could be used?
>>
>> Peter
>>
>>
>
--
Nicolas Desprès
At the moment, ninja on Windows uses CreateProcess to invoke build commands.
Therefore && cannot be directly used. However, it has been pointed out that to
use &&, all one needs to do is to start the command with cmd /c. I believe this
will also solve the requirements of file redirections, pipes and other things a
shell normally supports.
The answer to command line too long is to response files. I think Petr Wolf is
working on a patch.
If we need to use cmd and very long command lines, we only to pass the
commands to cmd in the form of response file (or batch script file).
Having said that, I'd be interested to hear what kind of problem can
be solved by
using the && syntax.
Regards,
Qingning
I've added support for && and argument/response files on Windows:
https://github.com/syntheticpp/ninja/commit/efa73bf5f9206e150b25742f68f26f5449ab3a50
It's the first shot, but I can compile CMake with this patch, the build has
custom build rules and command lines greater the 8.191 limit.
The patch is not ready for merging because some questions are still open:
1. (TODO 1 in the code)
We don't wanna parse the command line to find the command which is called with
the argument file. We could say where to place the arg/response file
when defining the rule, e.g. (I've choosen rsp because it is shorter than 'argfile'):
rule cxx
command = $cxx $rsp $flags
rspopt = @
Maybe the command line generation could be solved by simple variable handling.
1. evaluate and count with rsp="".
2. if to big "rsp == <generated file name>" and "command = $cxx $rspopt$rsp"
But I haven't tried it this way.
2. (TODO 2 in the code)
In the rule we must specify if the command supports argument files and how, e.g:
rule cxx
command = $cxx $rsp $flags
rspopt = @ # gcc @$argfile
a python script could look like this
rule pycmd
command = $pycmd $rsp $flags
rspopt = --very-much-options # pycmd.py --very-much-options $argfile
And having a default would help not to break too much existing code.
It isn't hard to port the argument file support to Linux: Finding a good tmp-file name
and patching checkForArgFile(string* command) so it could be used on all platforms.
Peter
It adds argument file support
For very long command lines put the arguments into a file.
Each rule can specify where to place the argument file.
On Windows such files are called 'response' files, therefore the abbreviation 'rsp'.
To pass a response file to a command a option must be used which is often '@'.
$rsp indicates the place where to place put the option.
rspopt is a rile-variable which defines the option.
Example:
rule cxx
command = gcc /Wall $rsp /Wextra $in
rspopt = @
build out: cxx foo1 foo2 foo3
-> gcc /Wall @/tmp/ninja_hX7jPD
with ninja_hX7jPD: /Wextra foo1 foo2 foo3
By default '@' is used after the first token in a command.
Only command chains are supported which use '&&'.
Comments are welcome.
-- Peter