This is true. Plus add debug bitbake, and debugging (or ignoring) broken caching, missing make semantic (delete a result artifact and see bitbake claim there's

This is true. Plus add debug bitbake, and debugging (or ignoring) broken caching, missing make semantic (delete a result artifact and see bitbake claim there's nothing to do) and generally causing a massive head-ache. But ... it has all the hooks you need, and even if it's a particularly ugly and broken behemoth, you can slowly steer it roundabout in the direction you want it to go. yocto also has more apes hitting the typewriter, so in some distant future it might even be sensible. My colleagues have evaluated buildroot vs. yocto several times, only to end up in yocto each time. I stopped challenging them: Once you have to hook into the build process in various places and implement your "around" hooks, yocto, while still sucking, and still standing in your way, and still pointing every gun there is at your feet ... doesn't make it impossible to achieve your goal without rewriting the whole thing. Also you can make more money with using a complicated, shiny tool, of course. NB: I'm using yocto professionally for three years now after a decade of experience in cross-building embedded targets using NetBSD. It is no joy (in contrast to NetBSD). If you don't have a problem that involves rewriting half of buildroot, choose buildroot :D