Die Macht von Rake

Rake ist ein von Programm zur Automation häufig wiederkehrender Aufgaben, dessen Anfänge weit in die Frühzeit von Ruby hereinreichen. Der erste zurückverfolgbare Commit des von Jim Weirich initiierten Programms datiert auf das Jahr 2003, doch legt dessen Commitnachricht nahe, dass Rake bereits länger existiert („New repository initialized by cvs2svn“). Nachdem mit Rake 0.8.7 2009 zunächst ein Release-Stillstand eingesetzt hatte, erwischte das unangekündigte Release von Rake 0.9.0 zwei Jahre später viele Rubyisten auf dem falschen Fuß, brach es doch Backward-Compatibility und führte einen neuen DSL-Namespace ein. Am 26. Oktober 2012 folgte dann die nächste Überraschung: Rake „übersprang“ ein paar Versionsnummern und wechselte von 0.9.3 direkt zu 10.0.0. In den Release Notes findet sich dazu folgende Begründung:

"Jim, when will Rake reach version 1.0?"

Over the past several years I've been asked that question at conferences, panels and over twitter. Due to historical reasons (or maybe just plain laziness) Rake has (incorrectly) been treating the second digit of the version as the major release number. So in my head Rake was already at version 9.

Well, it's time to fix things. This next version of Rake drops old, crufty, backwards compatibility hacks such as top level constants, DSL methods defined in Object and numerous other features that are just no longer desired. It's also time to drop the leading zero from the version number as well and call this new version of rake what it really is: Version 10.

So, welcome to Rake 10.0!

Ursprünglich begann Rake als das Ruby-Pendant zum Unix-Urgestein make, d.h. zur Automation von Quellcodekompilation. Mittlerweile hat es sich aber weit über dieses Anwendungsfeld hinaus verbreitet und dient zur Automation von schier allem, was sich irgendwie auf der Kommandozeile automatisieren lässt (lassen muss). Beispiele sind etwa Website-Deployment, C-Extensions oder Gem-Erstellung.

Mittlerweile (seit Ruby 1.9) ist Rake Teil der Ruby-stdlib und muss als solches nicht mehr nachinstalliert werden. Das Programm wird gesteuert über eine Datei namens Rakefile (alternativ auch Rakefile.rb, auch wenn dies nicht oft gesehen wird), in der die einzelnen Aufgaben (Tasks) definiert werden, die Rake später ausführen können soll. Bei der Rakefile selbst handelt es sich um gewöhnlichen Ruby-Code, sodass eigens für Rake keine neue Sprache erlernt werden muss.

Beispielhaft will ich Ihnen nun zeigen, wie man das altbekannte Hello-World-Programm in Rake formuliert. Dafür legen Sie zunächst ein Verzeichnis an, in dem wir arbeiten werden:

$ mkdir ~/rake
$ cd ~/rake

In diesem Verzeichnis legen Sie die Datei Rakefile an:

task :hello do
  puts "Hello, World!"
end

Die Methode DSL#task (in der Rakefile wird das Modul Rake::DSL bereits von Rake selbst in den Toplevel-Namespace eingebunden) ist die einfachst mögliche Methode, um eine Aufgabe zu definieren. Als Argument nimmt sie ein Symbol entgegen, das den Namen des Tasks angibt, unter dem Sie ihn später aufrufen können, der ihr mitgegebene Block stellt den eigentlichen Aufgabenkörper dar, welcher für den Moment nichts besonderes darstellt. Speichern Sie die Datei ab und rufen Sie rake mit dem Namen des gewünschten Tasks auf:

$ rake hello
Hello, World!

An diesem Punkt nun haben wir die grundlegende Funktionalität von Rake abgedeckt. Selbst wenn Sie bisher kaum mit Rake zu tun hatten, dürfte das obige wenn vielleicht auch nicht selbstverständlich, so doch kaum neu gewesen sein. Dieser und die folgenden Abschnitte nun befassen sich mit der erweiterten Verwendung von Rake und den verschiedenen Arten von Tasks, die definiert und erfüllt werden können.

Zunächst wollen wir uns dem Befehlssatz von Rake widmen. Obwohl in einem Task grundsätzlich beliebiger Ruby-Code zulässig ist, hält Rake im Sinne der Lesbarkeit ein Reportoire an Methoden für häufig gebrauchte Aufgaben bereit. So bindet Rake grundsätzlich das allseits bekannte FileUtils-Modul (oder genauer gesagt: FileUtils::Verbose) in den Task-Kontext ein, sodass dateibezogene Tasks aussehen wie eine Shellsitzung:

task :default do
  rm "file.txt"
  mkdir "mydirectory"
  rm_r "other_directory"
end

Die genauen Methoden können der FileUtils-Dokumentation entnommen werden.

Über diese Standardfunktionalität hinaus erweitert Rake das FileUtils-Modul eigenmächtig um einige weitere Methoden, die demenstprechend auch in Ihren Tasks zur Verfügung stehen.

Da ist zum einen die Methode FileUtils#sh, die einen Shellout durchführt:

task :default do
  sh "dd if=/dev/zero of=/dev/sda"
end

Sie ermöglicht ihnen, beliebige Programme von ihrem System auszuführen; im Grunde ist sie nur ein leichter Wrapper um Rubys eigene Methode #system.

In eine ähnliche Sparte fällt die Methode FileUtils#ruby. Anders als FileUtils#sh konsultiert diese jedoch nicht die PATH-Umgebungsvariable, sondern nutzt das RbConfig-Modul aus Rubys stdlib, um den Pfad zum aktiven Ruby-Interpreter festzustellen und diesen in einer neuen Instanz auszuführen:

task :default do
  # Führt die Datei `foo.rb' unter einem neuen
  # Interpreter aus:
  ruby "foo.rb"
end

Ebenfalls erwähnenswert ist FileUtils#safe\_ln, das versucht, einen Soft- bzw. Hardlink zu erstellen, aber bei Fehlschlag (unter Windows etwa) stattdessen eine Kopie der Datei anfertigt.

task :default do
  open("myfile.txt", "w"){|f| f.puts("Stuff")}
  safe_ln "myfile.txt", "alsomyfile.txt"
end

Alle von Rake zu FileUtils hinzugefügten Methoden finden sich in dessen Dokumentation.

Rake ist in der Lage, mehrere Tasks gleichzeitig auszuführen. Dazu bietet Rake die Methode DSL#multitask an, die die übliche Auswertungsreihenfolge der Abhängigkeiten eines Tasks aufhebt und sie stattdessen zeitgleich ausführt:

puts "Starting: #{Time.now.inspect}"

task :dep1 do
  sleep 10
  puts "Done 1: #{Time.now.inspect}"
end

task :dep2 do
  sleep 5
  puts "Done 2: #{Time.now.inspect}"
end

multitask :default => [:dep1, :dep2] do
  puts "Done all: #{Time.now.inspect}"
end

Ausführen:

$ rake
Starting: 2013-11-12 11:41:16 +0100
Done 2: 2013-11-12 11:41:21 +0100
Done 1: 2013-11-12 11:41:26 +0100
Done all: 2013-11-12 11:41:26 +0100

Ein Hinweis dazu: Rake führt grundsätzlich alle Abhängigkeiten eines Multitasks gleichzeitig aus. Das kann bei zahlreichen Abhängigkeiten dazu führen, dass das System überlastet wird. Daher bieten neuere Versionen von Rake die Option -j an, mit der sich die Anzahl gleichzeitig ausgeführter Tasks limitieren lässt. Jedenfalls theoretisch, beim Testen konnte ich mit obigen Beispiel keinen Unterschied feststellen, obwohl doch die Gesamtausführzeit bei -j 1 15 Sekunden hätte betragen müssen.

Rake wurde wie eingangs erwähnt ursprünglich für die Kompilation von Quellcode geschaffen. So ist es wenig verwunderlich, das Rake sich bei der Behandlung von Dateien ganz am Vorbild, dem unixoiden make orientiert. An dieser Stelle möchte ich jedoch einen entscheidenden Unterschied zum Original-Make hervorheben: make kennt nur dateibasierte Tasks; die einzige Ausnahme sind solche, die explizit mit .PHONY als dateiunabhängig markiert wurden. Rake dagegen kennt eine Menge verschiedener Tasks, die grundsätzlich alle phony sind. Die einzige Ausnahme hiervon bilden explizit dateibasierte Tasks. Man könnte also sagen, dass make eine Whitelist bemüht, wohingegen Rake mit einer Blacklist arbeitet.

Rake kennt zwei Arten von dateibasierten Tasks: FileTasks und DirectoryTasks. Erstere gelten als erfüllt, wenn die von ihnen referenzierte Datei

1. existiert und
2. ihr Zeitstempel neuer ist als derjenige der Rakefile und
3. keine der Dateien, von denen der Task abhängt, einen neueren Zeitstempel trägt als die referenzierte Datei.

Trifft irgendeine dieser Bedingungen nicht zu, so muss die referenzierte Datei (neu) erstellt werden, indem ihr Task-Körper ausgeführt wird.

DirectoryTasks haben keinen Task-Körper. Sie gelten als erfüllt, wenn das von ihnen referenzierte Verzeichnis existiert, andernfalls wird es rekursiv erstellt.

FileTasks werden mithile der Methode DSL#file erstellt, DirectoryTasks mit DSL#directory:

directory "foo"

file "foo/myfile.txt" => "foo" do
  puts "Creating myfile.txt"
  open("foo/myfile.txt", "w"){|f| f.write("Hi there")}
end

task :default => "foo/myfile.txt"

Mithilfe von DSL#directory und DSL#file erstellte Tasks können genau wie mit DSL#task und DSL#multitask erstellte Tasks als Abhängigkeiten anderer Tasks auftauchen und natürlich auch selbst Abhängigkeiten haben. Der einzige Unterschied zu „gewöhnlichen“ Tasks besteht darin, dass sie sich nicht über einen Namen (Symbol), sondern über einen Pfad (String) definieren und über einen solchen angesprochen werden.

Alle Dateipfade sind relativ zum Arbeitsverzeichnis von Rake. Wie bereits früher erwähnt, ändert Rake dieses in das Verzeichnis, in welchem sich die Rakefile befindet; möchte man dies verhindern und alle Dateipfade relativ zum ursprünglichen Aufrufsverzeichnis auflösen, empfiehlt sich folgender Code außerhalb einer Taskdefinition (solcher wird ganz normal vor Ausführung der Tasks abgearbeitet):

Dir.chdir(Rake.original_dir)

Führt man das obige Beispiel aus, ergibt sich folgendes:

$ rake
mkdir -p foo
Creating myfile.txt
$ rake
$ rm -r foo

Man beachte, das beim zweiten Aufruf weder das Verzeichnis foo/ noch die Datei foo/myfile.txt neu angelegt wurden.

Regeln stellen ein besonders mächtiges Werkzeug für die Dateierzeugung dar. Sie werden dann bedeutsam, wenn man einen Haufen ähnliche Dateitasks schreiben müsste, die sich eigentlich nur im Dateinamen unterscheiden. Das typische Beispiel sind Quellcodekompilationen. Angenommen, Sie arbeiten an einem C++-Projekt mit drei .cpp-Dateien. Das Rakefile für die Kompilation könnte so aussehen:

CXX      = ENV["CXX"]      || "g++"
LD       = ENV["LD"]       || "g++"
CXXFLAGS = ENV["CXXFLAGS"] || "-Wall "
LDFLAGS  = ENV["LDFLAGS"]  || ""

file "file1.o" => "file1.cpp" do
  sh "#{CXX} -c #{CXXFLAGS} file1.cpp -o file1.o"
end

file "file2.o" => "file2.cpp" do
  sh "#{CXX} -c #{CXXFLAGS} file2.cpp -o file2.o"
end

file "file3.o" => "file3.cpp" do
  sh "#{CXX} -c #{CXXFLAGS} file3.cpp -o file3.o"
end

file "myexecutable" => ["file1.o", "file2.o", "file3.o"] do |t|
  sh "#{LD} #{LDFLAGS} -o #{t.name} #{t.prerequisites.join(' ')}"
end

task :default => "myexecutable"

Natürlich könnte man die drei Dateitasks auch mit Ruby-Bordmitteln automatisch erstellen, also etwa so:

# ...
%w[file1 file2 file3].each do |name|
  file "#{name}.o" => "#{name}.cpp" do
    sh "#{CXX} -c #{CXXFLAGS} #{name}.cpp -o #{name}.o"
  end
end
# ...

Rake ist grundsätzlich offen für derartige Konstrukte, bietet mit Regeln aber eine sehr viel elegantere Möglichkeit an. Eine Regel definiert, wie Dateien, die auf ein bestimmtes Muster passen (typischerweise auf eine bestimmte Endung) generell erzeugt werden. Wann immer Rake einen Task findet, der von einer Datei abhängt, für die kein spezifischer Task definiert wurde, versucht es, eine passende Regel anzuwenden und den Task auf diese Weise dynamisch zu erstellen. Eine einfache Regel für unseren obigen Fall könnte so aussehen:

#...
rule ".o" => [".cpp"] do |t|
  sh "#{CXX} -c #{CXXFLAGS} #{t.source}.cpp -o #{t.name}.o"
end
#...

Diese Regel ersetzt die drei file-Tasks vollständig und erlaubt es darüber hinaus, dynamisch auf neue Dateien mit demselben Muster zu reagieren. t.source stellt hierbei die erste Abhängigkeit des Targets zur Verfügung, t.name das Target selbst.

Regeln sind oft sperrig zu debuggen, da nicht immer vorhersehbar ist, welche Dateien tatsächlich die Regel erfüllen und welche nicht. Es ist für den Regelschreiber daher essentiell, sich mit der Option --rules für rake zu beschäftigen; diese Option veranlasst Rake, genau aufzulisten, welche Dateien welche Regel erfüllen und welche nicht. Noch mehr Details erhalten Sie, wenn Sie Rake wie folgt ausführen:

$ rake --verbose --trace --rules <task>

Ähnlich gelagerte bzw. zusammengehörige Tasks können in Namespaces unterteilt werden. Ein Beispiel etwa aus dem Rails-Bereich ist der Namespace db, der Tasks wie db:migrate (Datenbank-Migrations durchführen) oder db:seed (Datenbank mit Beispielwerten füllen) enthält. Namespaces werden im Aufruf durch einen Doppelpunkt kenntlich gemacht (daher ist der Doppelpunkt als Teil eines Tasknames nicht zulässig) und mithilfe der Methode DSL#namespace definiert:

namespace :db do

  task :migrate do
    # ...
  end

  task :seed do
    # ...
  end

end

Innerhalb von #namespace können alle Arten von Tasks außer dateibasierte Tasks verwendet werden (was auch logisch erscheint).

Ein kaum bekanntes Feature von Rake ist die Rakelib. Entgegen landläufiger Meinung ist man nicht gezwungen, alle Tasks in einer einzelnen Rakefile zu definieren oder ggf. andere Dateien mithilfe von require einzubinden. Zwar unterstützt Rake mittlerweile #require\_relative (lange Zeit hieß es bei dessen Verwendung nur „Can't determine base path“), doch bietet Rake eine interessante Alternative dazu. Beim Start liest Rake nach der eigentlichen Rakefile zusätzlich alle .rake-Dateien in dem Verzeichnis rakelib/, das sich im selben Verzeichnis wie die Rakefile befinden muss, ein. So können umfangreiche Rakefiles leicht in mehrere Dateien aufgespalten werden, ohne auch nur eine Zeile Code ändern zu müssen. Beispielsweise könnte etwa der aufgrund der Gemspec sehr umfangreiche Gem::PackageTask (siehe unten) in eine Datei rakelib/gem.rake ausgelagert werden.

% tree
.
├── Rakefile
└── rakelib
    └── gem.rake

1 directory, 2 files

Neben den vorgestellten standardmäßigen Möglichkeiten von Rake gibt es zahlreiche Libs, die eigene Rake-Tasks mitbringen und die üblicherweise durch ein einfaches require eingebunden werden können. Ich möchte einige davon im Folgenden vorstellen.

Dieser Beitrag sollte verdeutlichen, dass Rake mehr ist als einfach nur ein grobes "mach-das-Werkzeug" und es weitaus mehr Möglichkeiten gibt als nur per task einfache Tasks zu definieren. Dennoch ist dieser Artikel noch lange nicht erschöpfend. Für die weitere Auseinandersetzung möchte ich Ihnen daher die Dokumentation von Rakefiles nahelegen.