"Cameron Gutman" <[email protected]> писал(а) в своём письме Tuesday, October 04, 2011 12:08 PM: > > But why is changing a build system "ALWAYS dramatic"? Why do we have > issues like this?
Its because Linux bot conversion was not done they way it should be. > This should have been done at least in 2 steps, not in one giant mess as we > have done. On my bot we had cmake builder added on-demand the moment CMake builds were mature enough to produce ISO. The switch to default CMake happenend here before the summer iirc and new BE is being tested since September. I think its enough steps. > We absolutely cannot have bugs introduced due to our build system. Good to know we can have weeks-lasting breakages from other components. Only build system must be perfect! > The mere fact that we have to deal with this only detracts from the > development of real code. I took a good hour trying figure out why the > hell I couldn't boot trunk when I was trying to test my ACPI fixes. The > the Vbox testbot was doing fine, yet I couldn't boot my builds on Vbox. > Only after reverting commits on rbuild and downloading the latest CMake > build did I realize that only CMake builds would actually boot HEAD > source code. First of all, ACPI is not the best example to bring out in this particular case. Secondly, we have two buildbots, and VBox one was running CMake builds when you tested ACPI. Thirdly, it only proves what i said before, running rbuild and cmake side by side is the thing responsible for distractions from ROS development. It uses our resources and time, in your example i would HAVE to be running twice the builds, for both cmake and rbuild, something i simply have no hardware to perform. And what you opt for IS running them side by side for much longer than I would want to. >I know I'm going to get "Well you should have used CMake, > then it would've been fine," but CMake can't even properly do > multithreaded compilation. My CPU usage using CMake is about 45%, while > CPU usage while using rbuild is close to 100% for the majority of the > build, and the build times reflect this. I am sorry to say that, but this problem is entirely your fault. Had you come out and tell someone about it, we would have a solution for you long ago. We had this issue in windows cmake and it was fixed long ago... you cannot expect 4 minute ReactOS build with only one core? > I look forward to adopting CMake but only when it's ready, and from the looks > of the slowness and > regressions, it's definitely not ready. We cannot fix any issues that are not reported and i dont recall you reporting anything in particular, besides some occasional comments that CMake is bad and is not working for you, only when the transition was nearing. In my opinion, some steps will have to be forced, and this switch is one of them. The longer we run rbuild and cmake side by side, the more regressions we are likely to create! The longer we go like that, more time and effort is needed to actually complete the goal, simply because you and others are reluctant to switch. It is you who should know best that drastic steps are sometimes necessary to finish up stuff. > Regards, > Cameron > -- With best regards Caemyr _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
