Unix Build Systems
2024-07-28 12:38:32 One core Unix idea was to have a toolkit of sorts, with many little tools and utilities that would do one thing each and do it well. They were designed for a monolithic system environment, working nicely by and among themselves, and with sufficient documentation and experience, the end user would be very productive.
Then other implementations of Unix arose, and they were not fully compatible. You may still see this sometimes when building software today based on Makefiles and shell scripts. For a start, there are many different shells.
The default system shell and make are used heavily in many Unix style systems.
Both have their own little built-ins and people have created hacks to cater for advanced logic, such as comparing (partial) strings and actual numbers. Speaking of which: Unix style systems are based on text processing so much that build systems show symptoms of the limitations of make and shell scripts. While they can be simple, few lines of instructions to the system, larger projects have grown Makefiles and scripts to hundreds or even thousands of lines and dozens to hundreds such files. Following along is extremely hard, especially to the end user trying to debug them. And it all falls apart very easily as soon as extra tools are in use for which there are different implementations. Beyond the make command and shells themselves, examples are sed, awk, and many more of the common Unix tools. That creates a problem for portability, so some build systems start with a bootstrapping process that builds such tools they rely on. However,
even the bootstrapping part has the same problem again, so developers need to be extremely careful to only use commands and syntax for bootstrapping that are available on all sorts of platforms and implementations out there, which is again hard to anticipate.
Then other implementations of Unix arose, and they were not fully compatible. You may still see this sometimes when building software today based on Makefiles and shell scripts. For a start, there are many different shells.
The default system shell and make are used heavily in many Unix style systems.
Both have their own little built-ins and people have created hacks to cater for advanced logic, such as comparing (partial) strings and actual numbers. Speaking of which: Unix style systems are based on text processing so much that build systems show symptoms of the limitations of make and shell scripts. While they can be simple, few lines of instructions to the system, larger projects have grown Makefiles and scripts to hundreds or even thousands of lines and dozens to hundreds such files. Following along is extremely hard, especially to the end user trying to debug them. And it all falls apart very easily as soon as extra tools are in use for which there are different implementations. Beyond the make command and shells themselves, examples are sed, awk, and many more of the common Unix tools. That creates a problem for portability, so some build systems start with a bootstrapping process that builds such tools they rely on. However,
even the bootstrapping part has the same problem again, so developers need to be extremely careful to only use commands and syntax for bootstrapping that are available on all sorts of platforms and implementations out there, which is again hard to anticipate.