I found the learning curve to be much easier with buildroot and compared to yocto whose build system is python but uses mixed shell/python to describe the build.
Builroot errors seemed to happen much less, and easier to understand compared to Yocto errors. Also seemed easier to corrupt the Yocto environment to the point of having to wipe and start fresh
Buildroot kconfig and TUI menuconfig was super simple to find and add packages to the rootfs, even custom ones patched in to tree to out of tree directories that could be added in with a config option.
Yocto AFAICT does not have a package discovery via TUI. You have to guess at package names, add them to you config and wait for build error to say not found. It will at least sometimes recommend similar named packages or the actual package name that eg provides the library you wanted. Otherwise it’s a search on openembedded to find package recipes that are not in the Yocto poky reference.
Adding OOT tree code to Yocto is pretty simple, once you figure out to write shell/python recipe
The makefile/Kconfig way of buildroot seemed much more intuitive especially given the kernel, busybox and uboot all use kconfig. So if you’re used to those, buildroot just seemed a natural extension to the rootfs.
> Yocto AFAICT does not have a package discovery via TUI
Depends what you mean by package discovery, but `oe-pkgdata-util find-path` may be helpful in determining what package would produce a certain binary.
Other than searching on open embedded like you mention, I am not aware of a way to do this if you have not already added the layer containing the recipe.
> `oe-pkgdata-util find-path`
Thanks for that one. Will keep it in mind.
With buildroot, I can use menuconfig to search for available packages and add them to the rootfs.
Yocto AFAICT you have to get the recipe name and manually add it to the rootfs via IMAGE_INSTALL:append
I really want to like Zig, but man, an unsafe language in 2024 is a hard sell (even to myself).