Announcing a new build tool, stirmake
25 views
Skip to first unread message
Juha-Matti Tilli
Apr 20, 2026, 12:34:34 AM (6 days ago) Apr 20
to ninja-build
Hello Ninja users,
Some time ago, I created a new open source build tool I call stirmake. Back then I was not aware of Ninja. One of the goals my build tool shares with Ninja is the need for extreme performance and correctness at the same time. Now my build tool is starting to be feature-complete.
Stirmake is packed with a huge number of features, but what it lacks currently is users.
What inspired me to create stirmake was reading Peter Miller's famous "recursive make considered harmful" and several times attempting to use GNU make non-recursively, finding creating good build systems in such a manner is tedious and dependent on features of GNU make not specified in POSIX, although arguably the non-recursive build systems are better than recursive ones.
Had I been aware of Ninja, I would probably have created the new build tool even then, as some of my design choices differ wildly from those of Ninja, although there are similarities such as support for rules having multiple target files, dependence on build commands, autodetection of CPU count, automatically cleaning built files and GNU make jobserver compatibility (although my tool supports the non-FIFO variant too, ninja supports only FIFO jobserver).
One difference is that stirmake attempts to be a high-level tool like a scripting language, whereas Ninja attempts to be an assembly language for describing builds. I heavily encourage users to build high-level constructs to describe the built product. This arises from my hatred of build system autogeneration tools and especially hatred of GNU autotools. In my opinion, build system autogeneration usually makes the whole system too slow for mere act of adding one C file to the build.
My opinion is that by making autogeneration practically necessary, Ninja makes the most difficult problem someone else's problem. For example, to add one C source file to Mesa graphics library that uses Meson and Ninja, running Ninja after the modification automatically invokes Meson and it takes as many as five seconds to recreate the Ninja rules. Ninja may be fast but by making the most difficult part someone else's problem will mean the most difficult part, i.e. generating the Ninja rules, will be the bottleneck.
Another difference is that I have a custom embedded programming language with support for proper data types. Thus, filenames can have spaces in them.
I support easily including build systems from git submodules. So, you can have a stirmake system in a submodule and then include that build system to another stirmake build system.
My build tool speaks the jobserver protocol both as a server and as a client, so it can be deployed one project at a time in a GNU make dominated world.
It is possible to invoke stirmake in any directory containing a Stirfile, even though the top level is several steps upwards in the hierarchy (the top level is automatically detected like git detects the .git root).
The syntax of Stirfile is more similar to Makefile than it is to a Ninja build file, although I made each file have a proper scope like recursive make and unlike inclusive make. Thus, in parent file you can set $CFLAGS = ["-Wall"] and in child file you can set $CFLAGS = [@$CFLAGS, "-O3"] -- the child file has its own scope and can access variables in the scope of the parent file.
As an advanced feature, the built system can affect the build system by adding rules and dependencies.
If you're interested in taking a look at the new build tool, please obtain it by recursively cloning https://github.com/Aalto5G/stirmake or by downloading an official release and you can find its user's guide at https://jmtilli.github.io/stirmakeguide/
Any further new discussion topics related to stirmake obviously should take place at the discussion forums of the Github project at Aalto5G, not here. For private messaging, I don't read my GMail but read juha-mat...@iki.fi instead.
BR, Juha-Matti
Some time ago, I created a new open source build tool I call stirmake. Back then I was not aware of Ninja. One of the goals my build tool shares with Ninja is the need for extreme performance and correctness at the same time. Now my build tool is starting to be feature-complete.
Stirmake is packed with a huge number of features, but what it lacks currently is users.
What inspired me to create stirmake was reading Peter Miller's famous "recursive make considered harmful" and several times attempting to use GNU make non-recursively, finding creating good build systems in such a manner is tedious and dependent on features of GNU make not specified in POSIX, although arguably the non-recursive build systems are better than recursive ones.
Had I been aware of Ninja, I would probably have created the new build tool even then, as some of my design choices differ wildly from those of Ninja, although there are similarities such as support for rules having multiple target files, dependence on build commands, autodetection of CPU count, automatically cleaning built files and GNU make jobserver compatibility (although my tool supports the non-FIFO variant too, ninja supports only FIFO jobserver).
One difference is that stirmake attempts to be a high-level tool like a scripting language, whereas Ninja attempts to be an assembly language for describing builds. I heavily encourage users to build high-level constructs to describe the built product. This arises from my hatred of build system autogeneration tools and especially hatred of GNU autotools. In my opinion, build system autogeneration usually makes the whole system too slow for mere act of adding one C file to the build.
My opinion is that by making autogeneration practically necessary, Ninja makes the most difficult problem someone else's problem. For example, to add one C source file to Mesa graphics library that uses Meson and Ninja, running Ninja after the modification automatically invokes Meson and it takes as many as five seconds to recreate the Ninja rules. Ninja may be fast but by making the most difficult part someone else's problem will mean the most difficult part, i.e. generating the Ninja rules, will be the bottleneck.
Another difference is that I have a custom embedded programming language with support for proper data types. Thus, filenames can have spaces in them.
I support easily including build systems from git submodules. So, you can have a stirmake system in a submodule and then include that build system to another stirmake build system.
My build tool speaks the jobserver protocol both as a server and as a client, so it can be deployed one project at a time in a GNU make dominated world.
It is possible to invoke stirmake in any directory containing a Stirfile, even though the top level is several steps upwards in the hierarchy (the top level is automatically detected like git detects the .git root).
The syntax of Stirfile is more similar to Makefile than it is to a Ninja build file, although I made each file have a proper scope like recursive make and unlike inclusive make. Thus, in parent file you can set $CFLAGS = ["-Wall"] and in child file you can set $CFLAGS = [@$CFLAGS, "-O3"] -- the child file has its own scope and can access variables in the scope of the parent file.
As an advanced feature, the built system can affect the build system by adding rules and dependencies.
If you're interested in taking a look at the new build tool, please obtain it by recursively cloning https://github.com/Aalto5G/stirmake or by downloading an official release and you can find its user's guide at https://jmtilli.github.io/stirmakeguide/
I have tested it at least on several versions of various Linux distributions, and also on the major BSDs (FreeBSD, NetBSD, OpenBSD, DragonflyBSD) and it seems to work on all of them, although in NetBSD the byacc is for some reason called only "yacc", and on OpenBSD you need to compile byacc manually or resort to using bison, since the yacc in base system lacks several features and a byacc package is not available. The official releases can be built without byacc and flex (the parser and lexer have been created automatically already for them).
Although stirmake is currently a stand-alone build tool, what might be doable in the future is using it to create Ninja build rules. Currently there's no such a feature, but I don't see any major impediment to having such a feature either. I'm convinced that with such a feature, stirmake+ninja would be faster than meson+ninja for example, but it's a good question whether it would be faster than stand-alone stirmake -- probably not. Having stirmake+ninja would also lose some important features such as ability to execute the build from any directory, including subdirectories in the project structure, and the difference that stirmake executes its commands in subdirectory (similar to recursive make) whereas ninja executes them from the directory having build.ninja might cause problems.
Any further new discussion topics related to stirmake obviously should take place at the discussion forums of the Github project at Aalto5G, not here. For private messaging, I don't read my GMail but read juha-mat...@iki.fi instead.
BR, Juha-Matti
Reply all
Reply to author
Forward
0 new messages