This will not be done before the freeze for 3.1 on Thursday.
Reverting 7243c951 will resolve the problem for ReactOS in
out-of-source builds. So, we either revert that or hope Ninja can
be fixed to deal with the large dependency lists w/out crashing.
In the discussion with Adam, he mentioned
On 10/08/2014 03:45 AM, Amine Khaldi wrote:
Reverting this change makes more sense
This is the simplest solution for the upcoming 3.1 release because
it just restores behavior to what 3.0 does. I've done it here:
Ninja: Limit custom command side-effects to build folder
On 10/07/2014 04:53 PM, Adam Strzelecki wrote:
In meantime I've pushed stage/cmp0055-disable-ninja-side-effects
that make CMake warn about this compatibility layer when such
phony rules are about to be emitted.
What I've been trying to say is that this is NOT about compatibility
with broken
This is the simplest solution for the upcoming 3.1 release because
it just restores behavior to what 3.0 does. I've done it here:
Okay. But still I feel like this is just workaround rather than solution for
the problem.
This is not about supporting projects that do it wrong. Ninja
wants
On 10/07/2014 03:22 AM, Amine Khaldi wrote:
Please note that from the http://www.cmake.org/Bug/view.php?id=14972
fixes on, we can no longer compile ReactOS.
Thanks for trying the development version and reporting this regression
before it was released.
We have many DEPENDS on files that exist
On 10/7/2014 8:47 AM, Brad King wrote:
Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972
fixes on, we can no longer compile ReactOS.
Also, if you really care about ReactOS, you could run a nightly cmake
dashboard. Or it is almost certain that it will get broken again. If
On 10/07/2014 04:09 PM, Bill Hoffman wrote:
On 10/7/2014 8:47 AM, Brad King wrote:
Please note that from thehttp://www.cmake.org/Bug/view.php?id=14972
fixes on, we can no longer compile ReactOS.
Also, if you really care about ReactOS, you could run a nightly cmake
dashboard. Or it is almost
To clarify as far as I understand it this particular issue is with building
ReactOS on regular Windows rather than using CMake under ReactOS.
Which of course doesn't mean that there shouldn't be a dashboard for it
nonetheless :)
Yup, this is what I understand. It isn't a problem with
As a result of this, it's no longer possible to use the new CMake to compile
ReactOS, which makes us see this as a severe regression, considering that
CMake is the build system we use to compile the project.
Adam, Brad and co, can you please help ?
If I understand correctly the change
On 10/07/2014 04:56 PM, Adam Strzelecki wrote:
(1) Are these .spec, .inf or .idl generated by some custom commands?
(2) If yes, are these files specified as an output of these subcommand
commands? If no, why?
From what I remember from the IRC discussion ...
They are regular (not generated)
On 10/7/2014 10:42 AM, Adam Strzelecki wrote:
Which of course doesn't mean that there shouldn't be a dashboard for it
nonetheless:)
Yup, this is what I understand. It isn't a problem with compiling CMake on
ReactOS, but problem of compiling ReactOS with latest CMake master.
I'll follow the
From what I remember from the IRC discussion ...
They are regular (not generated) source files that are listed as dependencies
(but not outputs) of custom commands.
Okay now I get it. So actually 7243c951 (Ninja: Don't limit custom cmd
side-effects to build folder (#14972)) is to blame not
On 10/07/2014 02:21 PM, Adam Strzelecki wrote:
So please either provide test case, or some info
[snip]
On 10/07/2014 03:20 PM, Adam Strzelecki wrote:
I had a talk with Amine, and the problem was that due 7243c951
their build.ninja was getting numerous extra phony entries that
were leading
This will not be done before the freeze for 3.1 on Thursday.
Reverting 7243c951 will resolve the problem for ReactOS in
out-of-source builds. So, we either revert that or hope Ninja can
be fixed to deal with the large dependency lists w/out crashing.
In meantime I've pushed
14 matches
Mail list logo
