Intel has tried multiple times for the embedded market, so far not that great.
I'm now watching the yocto project for what Intel is the main force behind, it is a bad idea(over engineered to say the least) with a few good people running it.
Better is a relative term and may be different between your use case and mine.
I found the LWN article to be very useful: https://lwn.net/Articles/682540/
The full "wisdom" of the internet: https://www.google.com/search?q=buildroot+vs+yocto
It seems like people tend to say Yocto is a bad idea, but that's just their gut feelings (and mine as well) with no substance in it except yocto's complexity.
-- Yocto is complex without giving you anything much back in exchange. Pathnames are longer, directory names are counter-intuitive and do not emphasize the main task of a developer/integrator: work with the source code. Probably more bearable if one only checks out the whole tree, starts the build and go on lunch... but then comes the next item:
-- Yocto is more resource demanding (again, personal, compared to some systems I used before): more memory, more CPU cores for the builder VM, more storage -- for the same build we did before.
-- Yocto fails its promise to decouple the delivery from the FOSS sofgtware: every once in a while, a public repo goes offline, and angry customers call back. One still has to deal with the public repos you pull into the build, no matter what yocto advocates told you -- might as well copy it into the tree already.
Buildroot suffers from some of the above as well (my BR experience dates from ~5 years ago, I am not a fan of it).
On the flip side, Yocto is probably cleaner than buildroot for cross-building. It could also be easier in including new components into the build, haven't tried that.
Over time, I worked out some personal indicators I use to gauge the building/versioning harness:
-- how many macros and environment variables the makefiles / scripts / receipes contain and refer to. The lesser is the better;
-- how easily I can navigate in the source code: how long pathnames, how much typing to go to another source file; how many additional pulls/checkouts/fetches/unpacks are required. etc.
-- how "cross-clean" building it is: all required host-, target- and cross- tools need to live inside the same tree, and be built during the main build if necessary. Having a mandatory separate VM is usually an o_O sign.
I've created a couple of simple buildroot packages and it was nearly trivial. The buildroot preference is touse cmake for the package build support - I went with that and was very happy with the level of effort required (low!).
http://docs.automotivelinux.org/docs/getting_started/en/dev/...