[cmake-developers] Ninja generator on Windows

[Peter Collingbourne]

On Wed, Feb 01, 2012 at 10:19:15PM +0100, Peter Kümmel wrote:
> 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.

Apologies for not replying to this sooner.

This caused custom commands to be double encoded, causing a test failure
on *nix.  I reverted part of your changes to fix the test failures and
also had a look at implementing the escaping rules correctly.  With the
changes I made, I was able to configure CMake successfully using the
token-splitter branch.

I found that on Windows (on my machine at least), some try_compile
runs were non-deterministic, and this caused build failures in CMake.
I also encountered the issue Oscar mentioned in the other thread
regarding the pdb file being locked (maybe the two issues are related).
But I was able to successfully compile most of LLVM/Clang on Windows.

Thanks,
-- 
Peter