[CMake] Why is Ninja generator disabled by default?

[Claus Klein]

Please tack a lock at my builds too

All of this errors are NOT caused by ninja!
http://open.cdash.org/buildSummary.php?buildid=2315144

But with ninja I get the same result.

Some of the errors are caused by the fact that I use the current gcc47  
compiler (build with macports), which does not understand the -arch  
options used by this tests!

For the X11 error here is a patch which fix it (missing include)

The others, no idea, but this is a makefile project, not ninja!

With regards,
Claus


On 22.05.2012, at 13:02, David Cole wrote:

> Please take a look at the CMake dashboard:
>
>   http://open.cdash.org/index.php?project=CMake
>
> I will allow the ninja generator to be enabled by default after  
> interested parties fix all the failing tests in the "Nightly  
> Expected" section related to the ninja generator submissions.
>
> Honestly, I was opposed to the ninja generator being merged to  
> 'master' and enabled at all because of the failing tests on our  
> dashboard. Luckily for all you ninja fans out there, I do not have  
> dictator powers. ;-)
>
>
> David
>
>
> On Mon, May 21, 2012 at 4:27 PM, Andreas Mohr <andi at lisas.de> wrote:
> Hi,
>
> On Mon, May 21, 2012 at 10:40:03AM -0400, cmake-request at cmake.org  
> wrote:
> > From: David Cole <david.cole at kitware.com>
> > I agree with Bill here -- we cannot turn it on by default until it  
> works
> > sufficiently for typical use cases.
>
> So, what would be needed to turn CMake on by default?
> 'cause it does not "work sufficiently for typical use cases" :->
> </asbestos_suit>
>
>
> While there might be backwards compatibility reasons for only actually
> having Ninja truly enabled once it truly works (after all after some  
> years
> certain user code may resort to merely checking whether the feature
> is provided or not, rather than doing sufficiently precise checks
> "well, in this CMake pre-beta it actually was still broken,
> and 3 days later they fixed it"),
> I cannot help but wonder whether this configuration (build-time  
> disabling
> rather than a slightly special way of runtime disabling)
> is hindering progress a bit due to artificially limiting developer  
> uptake.
> OTOH people who tend to like playing with certain bleeding edge  
> things (like me)
> are actually able to enable it manually - it's just somewhat more
> effort:
>
> > For specialized use cases, if you know you want to turn it on, you  
> can
> > easily re-build a CMake of your own that has it enabled. Simply  
> turn on the
> > advanced cache option CMAKE_ENABLE_NINJA when configuring CMake.
>
>
> Andreas Mohr
>
> --
>
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at http://www.kitware.com/opensource/opensource.html
>
> Please keep messages on-topic and check the CMake FAQ at: http://www.cmake.org/Wiki/CMake_FAQ
>
> Follow this link to subscribe/unsubscribe:
> http://www.cmake.org/mailman/listinfo/cmake

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120528/b6907ba6/attachment-0002.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: TestsX11HelloWorldX11.patch
Type: application/octet-stream
Size: 293 bytes
Desc: not available
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120528/b6907ba6/attachment-0001.obj>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.cmake.org/pipermail/cmake/attachments/20120528/b6907ba6/attachment-0003.htm>