rmk¶ ↑

rmk is a meta-build system that is inspired by tmk and uses Ninja as build system.

I have been using tmk for long. It was the build system made for my workflow: tmk is a build system implemented in Tcl. Working with tmk is easy and efficient if one is willing to follow it's implicit (naming) rules. Especially, the setup of a project and linking to other projects can be done quickly with only few specifications. However, maintaining or extending tmk is as hard as maintaining Tcl code.

rmk is a meta-build system implemented in Ruby. It generates build files for Ninja, which does then the hard work. This means rmk is lightweight compared to tmk as it does not implement the build process. The small code size and use of Ruby simplifies maintenance of rmk.

Why rmk?¶ ↑

This could be your Makefile aka RMakefile…

use_tool cxx                   # C++ compiler (plus linker)
cxx.define 'HAVE_OPENGL'       # add '-DHAVE_OPENGL' to compiler flags
use_package 'opengl','boost'   # external libraries
use_project 'other'            # link to other project libraries

… plain and simple, isn't it? All you have to do to build is

> rmk -gc all                  # generate ninja files and build
...                            # (work on project)
> rmk                          # build default configuration

This will generate a Ninja file that builds a project library and executable binaries linked to OpenGL and boost libraries. Source files for binaries are detected automatically, all other sources are put in the project library. Binaries are linked to the project library, to the project library of the other (rmk) project and (if transitive linking is enabled) to all libraries required by other.

Different sets of, e.g., compiler flags are defined for the default (no optimization, include debug information and the max (maximum optimization). Each configuration goes to its own build directory. Configurations for generating and building are by a command line switch.

Design goals¶ ↑

Simple configuration¶ ↑

• Simple definition and use of external packages (libraries, code generators, etc.)

• Projects share global configuration (per host system)

• Simple configuration of tools (compilers, linker)

• Minimal need for specifications

• Maximize use of implicit rules (e.g., determine build of executable program)

• Simple changes to configuration (e.g., switch gcc for clang compiler or use ccache)

Simple use of multiple build configurations¶ ↑

• Define multiple build configurations (e.g., “debug”, “release”)

• Generate multiple build scripts

• Don't switch current working directory

Simple linking to projects built by rmk¶ ↑

• Implicit naming of libraries

• Simple transitive linking

Non-goals¶ ↑

• No automatic configuration

• Explicit specifications that diverge significantly from implicit rules are not encouraged.

• Not intended as an installation/deployment utility

• No multi-platform support (currently Linux/Unix only)

Rmk vs CMake¶ ↑

• rmk features a small DSL based on Ruby which makes extensions of rmk simple. The DSL is used for defining and using packages in the RMakefile. The definition of tools works similarly. CMake uses its own, proprietary scripting language.

• CMake may serve as an installation utility for “end users”. This is not a goal of rmk.

• rmk uses a global configuration that is maintained “manually” and shared among projects. CMake is configured per project. Configuration largely automatic but may use different mechanisms (e.g., to find packages), which are often reinvented per project.

• rmk is designed to minimize effort for combining own projects. There is no similar support by CMake.

Rmk vs Make or Rake etc.¶ ↑

• Make and the Ruby build tool Rake are a build tools similar to Ninja. (Rake defines DSL based on Ruby for this purpose.) rmk is “only” a meta-build tool.

• I chose Ninja as build tool. Rake or Make would be alternatives but there are currently no plans to support anything but Ninja.