Rōnin
A straightforward but powerful build system based on Ninja and
Python, suitable for projects both big and small.
Rōnin comes in frustration-free packaging. Let's build
all the things!
Features
Currently supported out-of-the-box:
all gcc languages,
Java,
Rust,
Go,
Vala/Genie,
pkg-config,
Qt tools,
sdl2-config, and
binutils.
It's also easy to integrate your favorite
testing framework.
"Based on Python" means that not only is it written in Python, but also it uses
Python as the DSL for build scripts. Many build systems invent their own DSLs, but Rōnin
intentionally uses a language that already exists. There's no hidden cost to this design choice:
build scripts are pretty much as concise and coherent as any specialized DSL. You don't need to be
an expert in Python to use Rōnin, but its power is at your fingertips if you need it.
Rōnin supports Unicode throughout: Ninja files are created in UTF-8 by default and you can include
Unicode characters in your build scripts.
Python 3 is recommended, but Rōnin can also run on Python 2.7.
Download
The latest release is available on PyPI. To install on
Debian/Ubuntu:
sudo apt install python3-pip
sudo -H pip3 install ronin
You also need Ninja. To install on Debian/Ubuntu:
sudo apt install ninja-build
Note that Ninja is a small self-contained executable, so you might prefer to just download
the most recent release. For Rōnin to be able to
run it, it must be in either your execution path or the current directory. Or, you can run your
build script with --set ninja.command=
and give it the full path to Ninja.
Also note that instead of requiring your users to download Rōnin and Ninja, you can opt to
include both with your project.
Documentation
An undocumented system is a broken system. We strive for coherent, comprehensive, and up-to-date
documentation.
A detailed user manual is available on the wiki.
If you prefer to learn by example,
there are many.
Rich API docs available on Read the Docs.
Feelings
Guiding lights:
- Powerful does not have to mean hard to use: optional auto-configuration with sensible,
overridable defaults.
- Complex does not have to mean complicated: handle cross-compilation and other
multi-configuration builds in a single script with minimal duplication of effort.
Design principles:
- Don't hide functionality behind complexity: the architecture should be straightforward. For
example, if the user wants to manipulate a compiler command line, let them do it easily. Too many
build systems bungle this and make it either impossible or very difficult to do something that
would be trivial using a shell script.
- Pour some sugar on me: make common tasks easier with sweet utility functions. But make sure
that sugar is optional, allowing the script to be more verbose when more control is necessary.
- Don't reinvent wheels: if Python or Ninja do something for us, use it. The build script is a
plain Python program without any unnecessary cleverness. The generated Ninja file looks like
something you could have created manually.
FAQ
- Do we really need another build system? Yes. The other existing ones have convoluted
architectures, impossible to opt-out-from automatic features, or are otherwise hostile to
straightforward hacking. After so much wasted time fighting build systems to make them work for
us, the time came to roll out a new one that does it right.
- Python is too hard. Why not create a simpler DSL? Others have done it, and it seems that the
costs outweigh the benefits. Making a new language is not trivial. Making a robust language
could take years of effort. Python is here right now, with a huge ecosystem of libraries and
tools. Yes, it introduces a learning curve, but getting familiar with Python is useful for so
many practical reasons beyond writing build scripts for Rōnin. That said, if someone wants to
contribute a simple DSL as an optional extra, we will consider!
- Why add Ninja, a binary, as a dependency, instead of using 100% Python? Because it's silly
to reinvent wheels, especially when the wheels are so good. Ninja is a one-trick pony that does
its job extremely well. But it's just too low-level for most users, hence the need for a frontend.
You can use Rōnin to just generate the Ninja file via the
ninja
operation.
- Did you choose Ninja because it's fast? No. Ninja was chosen because of its marvelous
minimalism. Its reputation for speed is unfounded: running Make in parallel mode (the
-j
flag)
is equally
fast for most use cases.
It's not Make that is slow, but rather the complex Autotools configuration phases added on top of
it by many projects. In addition to Ninja, we also considered tup.
Similar Projects
- bfg9000: "bfg9000 is a cross-platform build configuration
system with an emphasis on making it easy to define how to build your software."
- Craftr: "Craftr is a modular meta build system that
primarily targets Ninja as the build backend."
- Meson: "Meson is an open source build system meant to be both extremely
fast, and, even more importantly, as user friendly as possible."
- pyrate: "pyrate is a small python based build file
generator targeting ninja(s)."