On Oct 4, 2011, at 10:06 AM, [email protected] wrote: > I could also add intl.cpl not working in 2nd stage setup. Still, those > regressions, apart from the KVM one are meaningless, compared to the profits > CMake brings. Changing build system/buildchain is ALWAYS dramatic and > troublesome. We cannot stop it, as supporting CMake and rbuild at once is > purely a waste of resources. There is no going back to rbuild, Cameron. >
But why is changing a build system "ALWAYS dramatic"? Why do we have issues like this? We're not changing the compiler, linker, assembler, or any source (in theory, but not really). The real build tools (GCC, LD, GAS, etc) should be receiving the same parameters for the build in the end whether via the CMake frontend or the rbuild frontend. So either the new debugging symbol stuff is exposing/creating bugs in the code, or CMake is not passing the same parameters to the build chain as rbuild is. The reason we're having trouble is because we tried to do too much with this change at one time. It's the same reason Intel does the tick-tock release cycle. We've changed our build system, changed the type of symbols in our binaries, and made CMake-specific modifications to our code (to read the symbols). This should have been done at least in 2 steps, not in one giant mess as we have done. We absolutely cannot have bugs introduced due to our build system. All the build system provides is a nicer way to talk to the core build tools. That shouldn't be causing a problem unless something is wrong in the CMake configuration files. In which case, that must be corrected before CMake is adopted. 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. 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 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. Regards, Cameron _______________________________________________ Ros-dev mailing list [email protected] http://www.reactos.org/mailman/listinfo/ros-dev
