The thing I love about engineers and working with engineers is that they rarely leave well enough alone.
Particularly software engineers. They work with computers every day. Any kind of activity which is repetitive and boring is perfect to farm out to a computer.
Imagine a carpenter who is able to improve the efficiency and speed of their hammers, power saws and drills by incrementally tweaking them or redesigning them every day.
I posted recently about how Linux has no official build system or methodology. And if you are an embedded developer and you want to build your own Linux-based OS, there is no standard build system or methodology. So, you either need to create one or adopt one.
I also talked about the natual progression of how build systems are developed, which seemed to really resonnate with the attendees at the 8th International System-on-Chip Conference. Here is the natural progression we often see to get to a consistent, repeatable, reusable OS build:
- Scripts – like my previous work at Sequent, a logical starting place is to write a shell script or a cascade of nested shell scripts. This works in a pinch for a one- time effort. But what happens if you patch a component or upgrade it? A script does not automatically know what changed, compute the dependencies and recompile the affected pieces. You may be best just to recompile the whole world every time. Yuck. This can make you old very quickly or at least feel very old. Oh, and what happens on the next project? You may need to just throw the whole mess away and just start all over again.
- Makefiles – to solve the dependency effect, maybe you want to use the make command. After all, computing dependencies is the main reason why the make command exists. You also begin to define meta-data, a rule for doing things rather than just the scripted commands themselves. The problem comes when you want to fetch things over the internet rather than have them local. Or define caches of pre-built packages and determine what to rebuild when the dependencies change, even when these caches are on other servers and the system clocks get out of synch. It may be possible to do some of these things with make, but it’s going to take a lot of extensions.
- Build systems based on meta-data – now we’re talking! Create a build system-specific language which is designed for building operating systems. Don’t be limited by make’s limitations, but use it when you need to. So many opportunities now exist for this.
Thus, we eventually get to systems like Open Embedded and Poky. And honestly, this is why we decided not to try to reinvent the wheel, but take an existing project (Poky) and enhance it.
