3 ms·

Thanks! The article is useful indeed. 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 subst

Thanks! The article is useful indeed. 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.

minipci1321 9y ago
I have been trying to answer to myself the same question as you are, and below my personal experience of learning-curve climber: -- 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.
- gvb 9y ago
  FWIW, buildroot now has the ability to build a complete cross build environment (I've used ARM and PowerPC). This is a configuration option: buildroot's cross or an external cross build environment. Buildroot does the Right Thing: all the required host-, target- and cross- tools need to live inside the same tree. This includes the option to build lib_.a (non-shared) cross libraries on the host, statically link against them for the target executable, and only install the target executable on the target installation (no carrying lib_.a baggage on the target file system). 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!).

Thanks! The article is useful indeed. 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.

minipci1321 9y ago

I have been trying to answer to myself the same question as you are, and below my personal experience of learning-curve climber: -- 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.

gvb 9y ago
FWIW, buildroot now has the ability to build a complete cross build environment (I've used ARM and PowerPC). This is a configuration option: buildroot's cross or an external cross build environment. Buildroot does the Right Thing: all the required host-, target- and cross- tools need to live inside the same tree. This includes the option to build lib_.a (non-shared) cross libraries on the host, statically link against them for the target executable, and only install the target executable on the target installation (no carrying lib_.a baggage on the target file system). 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!).