Why would I want to use this instead of ninja? It’s apparently a drop-in replacement but it doesn’t say what it’s trying to do better than the original.
The code is readable and maintainable, and can be used in the Linux distro that the author maintains without pulling in a huge number of dependencies to build a C++ compiler.
“written in C99 with a focus on simplicity, speed, and portability” is what appears to differentiate it from ninja. if that sounds interesting you should check it out and if not skip it
Ninja is already fast, simple, and portable, so those aren’t differentiating factors. It appears to just be ninja but written in a different programming language.
Neat, but I wonder what the motivation for this is. I assumed that for the majority of projects ninja itself adds little overhead to the total build time.
Doubtful. Both GCC and LLVM are written in C++ so you have to build a C++ compiler irrespective of whether you actually want one!
I suspect it's more that they don't like C++ and want to use C for everything. Whether that actually translates into a higher quality tool or a more performant tool, we can only imagine.
Ehhh, the creator also works on a minimalist Linux distro (Oasis) and one of their goals is to build with cproc (a C frontend for the QBE backend), all written in ISO C. He uses Samurai in his distro, so it all fits together pretty well
You can just use a GCC version < 4.8 or something like e.g. TCC if you want to avoid C++.
Though Ninja is implemented in a very moderate C++ style; I'm able to compile it even with GCC <= 4.8; it even seems to compile on pre-C++11 compilers.
Muon is a very nice project; especially the bootstrap means are great; unfortunately it doesn't seem to run on Windows and personally I don't think that Meson is a much better system/language than e.g. CMake; otherwise I would have used Muon instead of implementing BUSY.
Neat. I like keeping track of ninja implementations (I'm a CMake developer), but it's unfortunate how many end up skipping `dyndep` support (granted, it is not trivial) because it is necessary to reliably build C++20 modules (and Fortran modules FWIW).
It's probably fine since it seems to be built for a minimal platform where saying "no" to C++ (nevermind C++20) is possible, but I wonder how many people know that the number of tools that can reliably support C++20 is far smaller than it has been historically.
26 comments
[ 4.1 ms ] story [ 75.0 ms ] threadhttps://github.com/oasislinux/oasis
https://sr.ht/~mcf/cproc/
I suspect it's more that they don't like C++ and want to use C for everything. Whether that actually translates into a higher quality tool or a more performant tool, we can only imagine.
Though Ninja is implemented in a very moderate C++ style; I'm able to compile it even with GCC <= 4.8; it even seems to compile on pre-C++11 compilers.
There is also Muon [1] for Meson (Python).
[1]: https://sr.ht/~lattis/muon/
There are minimal C compilers written in C around, though, admittedly, not as relevant as GCC/clang/MSVC
As much as I believe this to be true in politics, I think it's really really wrong, if not actively harmful, in tech
The improvement upon the program 'more' was named 'less'. It seems to be a tradition to choose opposites rather than similar words.
Samurai were warrior-governors of Japan, much like Knights. Their opposite and enemy were ninjas/Shinobi, the spies and assassin's of Japan.
https://news.ycombinator.com/item?id=30806875
It's probably fine since it seems to be built for a minimal platform where saying "no" to C++ (nevermind C++20) is possible, but I wonder how many people know that the number of tools that can reliably support C++20 is far smaller than it has been historically.
this phrase is such rarity in titles these days, that it is newsworthy in itself.