Re: Abridged summary of ninja-build@googlegroups.com - 1 update in 1 topic

[Basile STARYNKEVITCH]

On Mon, 2026-04-20 at 00:22 -0700, ninja...@googlegroups.com wrote:

ninja...@googlegroups.com

Google Groups

Today's topic summary
View all topics

• Announcing a new build tool, stirmake - 1 Update

Announcing a new build tool, stirmake

Juha-Matti Tilli <jmkt...@gmail.com>: Apr 19 10:33AM -0700 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 ...more

Back to top

You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page. To unsubscribe from this group and stop receiving emails from it send an email to ninja-build...@googlegroups.com.

I would suggest a few features;

0. Obey to the GNU/Linux conventions of accepting --version and --help, the current Usage: output is really cryptic and an output (for --help ...) of twenty lines would be helpful.

1. Accept longer and more meaningful arguments; e.g. smka -bc is cryptic and could also be smka --clean-binaries and explain how to clean generated C (or C++...) files.

2. Consider adding some plugin abilities.

3. Perhaps embed a good (ie Turing complete) scripting language eg GNU guile

4. Improve the documentation, e.g. more examples such as how to use the carburetta parser generator https://carburetta.com/

5. A build can have several flavors. I love (since GCC allows that) to compile with both optimization and debug information.

A very warm and big thanks for your new build tool.

Basile STARYNKEVITCH                            <bas...@starynkevitch.net>
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

[Juha-Matti Tilli]

Hello,

And thanks for the commentary!

(Maybe you should have replied to the original message, not to the topic summary.)

0. (help output) This is actually because I come from the BSD world. If you type "make -h" on FreeBSD, you do in fact get a cryptic summary. To obtain the full information, you type "man make" in FreeBSD, and for stirmake, it would be "man stirmake", "man smka", "man smkt" or "man smkp". But in fact, it's not a given that the summary is short in BSD, as byacc -h has pretty tidy output. So maybe I should tidy up the output to be less cryptic and have more information.

1. (longer and more meaningful arguments) This is something I have to seriously consider, but lack of POSIX standardization of getopt_long means it's not easy. One option would be to allow compiling both with and without getopt_long, but it would mean differently compiled versions of stirmake would be different, and operating systems that don't have getopt_long would have a different tool than GNU/Linux. Another option would be to embed some non-GPL'd implementation of getopt_long in the repository and use it on all operating systems, maybe renaming it from getopt_long to stir_getopt_long to have a different symbol name. (With compilation options, you could then select to use the libc version if it already has getopt_long.) Maybe some of the BSDs could have code that I find has acceptable licensing and enough features.

2. (plugin abilities) I'm not sure what this means. Plugin as in something done with a scripting language? (The embedded language Amyplan and Lua/LuaJIT can be used for that.) Plugin as in .so library to be loaded into stirmake's address space? That's something I probably won't do.

3. (scripting) I'm pretty certain stirmake is already Turing-complete, but I can't call the embedded language "good", although it is "better" than the embedded programming features in GNU make if you compile GNU make without Guile (bare GNU make probably is Turing complete but in a manner similar to Brainfuck). However, there's Lua bindings, not only for standard Lua but also for LuaJIT. This Lua support is something I have to document better in future releases. Guile I won't choose, I counted 237 000 lines in it vs 87 000 in LuaJIT or 32 000 in standard Lua. The only more monstrous language implementation than Guile that I'm aware of is Google's V8 JavaScript engine and maybe Python (although as a language Python is nice if you don't look under the hood). Bindings to some other non-(L)GPL'd Scheme implementation is something I could consider, as long as it is small, true to the ideal of Scheme that Guile has broken with their monstrous implementation.

4. (documentation) At least AI who has read my docs at https://jmtilli.github.io/stirmakeguide/ find that they seem to be pretty comprehensive.

5. (flavors) This is in some cases arguably dangerous. If you compile with and without debug information, and distribute the binary without debug information to customers, and try to analyze coredumps with the binary with debug information, it's garbage-in, garbage-out. The builds are different. So my opinion is that you should always build with debug information and only afterwards create separate stripped binaries from the debug builds. This allows analyzing coredumps from binaries shipped to the customers. (You can see here I come from the commercial world, not from the open-source world, as not distributing source code to customers is standard practice there.) However, optimization flavors for large projects are something that could be desirable, but I feel supporting them in the tool itself would deviate from the ideal of what standard make does (make leaves supporting them up to the user). I'm not entirely convinced the world requires another CMake or Meson, as CMake and Meson seem to be doing just fine. But the world in fact requires another make, because the solutions to the "Recursive Make Considered Harmful" paper are lacking. That's why it's named Stirmake, not Stirmeson.

Thanks for the commentary again! I opened four issues in Github based on them.

BR, Juha-Matti

[Nico Weber]

Thanks for the announcement, but detailed discussions for a different build tool seem off topic for this mailing list :) Please consider setting up your own mailing list and discussing your tool there (or discourse or discord server, or whatever forum you choose).

Nico

--
You received this message because you are subscribed to the Google Groups "ninja-build" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ninja-build...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/ninja-build/e9fde80b-01d9-4cf3-9acc-56e6404ad7bdn%40googlegroups.com.