3 ms·
Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on
by palata 2y ago
Yocto is pretty great! Unfortunately I feel like it gets a lot of criticism, but usually from people who haven't gotten to learn it. Like "I had to spend 2h on Yocto and this thing suuuuucks, I threw a docker image there and called it a day".
Which is a pity, because when used correctly it's really powerful!
From the article, I can't help but mention that one third of the "key terminology" is about codenames. What do people have with codenames? I can count and easily know that 5 comes after 4. But I don't know how to compare Scarthgap and Dunfell (hell, I can't even remember them).
- lukeh 2y agoYeah, I was a bit scared off by it and both the terminology and the curious mixing of Python and bash can be a bit confusing. But it’s powerful and also very extensible without (generally) having to fork upstream layers.
- allo37 2y agoI'm honestly impressed by how...well it works. Considering it's building an entire, totally custom Linux distro from scratch it requires a surprisingly little amount of hand-holding.
- bibabaloo 2y agoI agree. I don't understand how people prefer buildroot. Buildroot feels like an adhoc system of glued together Makefiles, whereas yocto actually feels like it was built for purpose.
- xedrac 2y agoYocto feels like a ball of mud duct taped together, but thankfully has good documentation. It reminds me of CMake. Buildroot is nice for relatively simple situations. Nixos is arguably better than both.
- ahartmetz 2y agoTheir idiosyncrasies may look similar, but CMake has a much stronger skeleton of core algorithms and data structures for a build system than Bitbake. Specifically, as I mentioned in another reply, Bitbake does not model dependencies correctly. CMake does.
- nrclark 2y agoCan you elaborate a bit on the dependency-handling topic? I've always thought that Bitbake's dependency handling worked pretty well. It only has package-level granularity, but is quite good within that context.
- ahartmetz 2y agoAs of five years ago when I last used it: Bitbake doesn't model all changes that affect packages, so after certain changes, some packages that should be rebuilt, aren't. It is especially prone to happen when changing Bitbake variables (example: MACHINE_FEATURES), and these are a quite common way to change things about the image being built.
- cushychicken 2y agoPart of why it gets so much criticism is that Yocto’s learning curve is pure brutality. Out of the box configurations for Yocto images and recipes are fabulous. Trying to modify those configurations below the application layer… you’re gonna have a bad time. Opaque error messages, the whole layers vs recipes vs meta issues, etc. I also can’t shake the feeling that yocto was made to solve a chip company’s problems (I.e. supporting Linux distros for three hundred different SOCs) rather than my problems (I.e. ship working embedded software for one or two SOC platforms). I’ve had a lot more success with buildroot as an embedded Linux build system and I recommend it very highly.
- eschneider 2y agoThis is truth. I've done a lot of work bringing up custom boards with both Yocto and Buildroot and I rather like Yocto. But yeah, first project with Yocto was painful. It's rather well documented, but one really needs a good idea of what's going on to really know what you're even looking for. That said, once you get it figured out, it's very flexible and largely logical. :)
- ahartmetz 2y agoIME, the documentation is kinda useless when the going gets tough. But the code is surprisingly easy to follow.
- eschneider 2y agoThe docs are good in the "I think there should be a way to do X" and if you have a good sense of how Yocto is organized, you'll know where to check if X exists. That's...not a trivial thing.
- ahartmetz 2y agoTrue. For the most part, the documentation tells you what you can do in general terms and where (which file / variable). That is useful, but not enough to know how to do it.
- rcxdude 2y agoIt's powerful but bitbake wasn't so much designed as emerged from a primordial soup, it's easy to go completely insane trying to debug it due to the amount of action-at-distance recipes and layers can create. (try playing the "where did this compile flag come from?" game)
- whiatp 2y agobitbake -e <recipe> is super useful for that game. It dumps out a complete history of where all variables were set/changed, and their values along the way. I also use it to do what I call "variable shopping," where I roughly know what path/name content I need, but not what the variable it is in is called.
- nrclark 2y agoI don't disagree, but wanted to note- if you're ever stuck trying to trace a value, you can see everything that went into its calculation by using "bitbake -e".