[cmake-developers] Ninja generator on Windows

[Peter Kümmel]

On 31.01.2012 23:40, Peter Collingbourne wrote:
> On Tue, Jan 31, 2012 at 10:32:23PM +0100, Peter Kümmel wrote:
>> On 31.01.2012 16:19, Peter Collingbourne wrote:
>>> On Tue, Jan 31, 2012 at 12:15:59AM +0100, Peter Kümmel wrote:
>>>> - Paths like 'c:\' - Ninja now supports colon escaping "c:" ->   "c$:"
>>>>     Is there a single place where the escaping could be done?
>>>
>>> ':' only needs to be escaped in identifiers.  So
>>> cmGlobalNinjaGenerator::EncodeIdent is the correct place.
>>
>> Also the colons in drive names must be "escaped". For instance,
>> when you wanna configure ninja to build the tests with gtest
>> at C:\gtest-1.6.0, you have to call
>>
>>       python configure.py --with-gtest=c$:\gtest-1.6.0
>>
>> this generates the rule:
>>
>> build $builddir\gtest_main.o: cxx $
>>       c$:\gtest-1.6.0\src/gtest_main.cc
>>
>> Without the $: the build script does not work.
>
> Sorry if I wasn't clear here.  When I wrote "identifiers" I was
> referring to lexicographical identifiers in the Ninja grammar.
> Path names in build statements are lexed as identifiers, and so must
> be escaped.  But variable values (including those containing paths)
> are not lexed as identifiers so there is no need to escape anything
> other than '$'.  All path names destined to be output as identifiers
> should already be going through cmGlobalNinjaGenerator::EncodeIdent.

Ok, but I also had to "EncodeLiteral" the commands, but this function
is obsolete when we maybe use KWSys.

>
> Probably the lack of correct identifier escaping for Ninja's configure
> script is a bug in ninja_syntax.py.
>
>>>> - Finding the msvc compiler fails because TARGET_IMPLIB is empty
>>>>     and to the linker /implib: is passed without an argument.
>>>>     Why is TARGET_IMPLIB empty?
>>>
>>> Probably because cmLocalGenerator::TargetImplib is not being
>>> set.  Look at how the makefile generator does it.
>>>
>>
>> Do you think much win32 stuff is missing? I ask, because you've based
>> the ninja generator on a Makefile generator, or I'm wrong?
>
> No idea.  I've never tried the generator on Windows.  We're probably
> at least 3/4 of the way there though.
>
>>>> - Some targets have the .exe extension, but the rule misses the .exe.
>>>
>>> Can you show an example of what you mean?  The generator should be
>>> using cmTarget::GetFullPath to build paths to targets which seems
>>> to append CMAKE_EXECUTABLE_SUFFIX (i.e. ".exe" on Windows) where
>>> necessary.
>>
>> Is was a bug in my CMakeLists.txt because MSVC_IDE was set, even when I use
>> the Ninja generator.
>>
>> Currently I use "CMAKE_GENERATOR STREQUAL Ninja" the check for the ninja generator.
>> Is there a simpler way? Couldn't we set NINJA or CMAKE_NINJA?
>
> I don't see any reason to be inconsistent with the other generators.

Aren't the other generators inconsistent? MSVC and MSVC_IDE is defined but no
XCODE, ECLIPSE(?).

>
>>>> - When&&   is used for calling multiple command a 'cmd.exe /c' call is necessary.
>>>
>>> Correct.  That will need to be prepended in
>>> cmLocalNinjaGenerator::BuildCommandLine if the vector contains more
>>> than one command.
>>
>> When there are no PRE and POST steps the cmd and&&  could be dropped completely
>> (also the "cd ." nop, which I've used instead of ":")
>
> Yes.
>
> I've reminded myself of something.  Remember that BuildCommandLine
> is used to build both "full" command lines and sub-command lines
> (such as lists of PRE and POST commands) and consider the case where
> the sub command line contains more than one command.
>
> COMMAND = cmd /c $PRE&&  foo&&  $POST
> [...]
> PRE = cmd /c foo&&  bar
> POST = cmd /c foo&&  bar
>
> Note the multiple "cmd /c"s.  I don't know what Windows will think
> of that but it makes me nervous and in any case will probably slow
> the build down.  We might need a pair of functions, one for building
> full command lines and one for sub command lines.
>

We can't use cmd. Maybe ninja could be fixed.


> Thanks,