4 Oct
2011
4 Oct
'11
4:08 p.m.
On Oct 4, 2011, at 10:06 AM, caemyr(a)myopera.com 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