Bob, your friendly builder

Hello World

Put this in a file named bob_config.php in your project's root:

<?php

namespace Bob\BuildConfig;

task('default', ['hello']);

task('hello', function() {
	echo "Hello World!\n";
});

Run this on your shell:

$ php composer.phar require chh/bob:~1.0@dev
$ vendor/bin/bob

What is Bob?

This is Bob. Bob is a lightweight project automation tool in PHP similar to Rake.

Bob can be used as general build tool, but really shines when used in PHP projects as you are capable of reusing existing Application Code and Libraries in your buildfiles.

How Bob compares to Pake:

• Bob uses a set of namespaced functions for the DSL, so PHP 5.3 is a must. If you need 5.2.x support, look at Pake.
• Bob's task definitions directly take a closure for the task's body, instead of performing magic with functions named run_<task name>.
• Bob has no file finder similar to pakeFinder, if you need this just use the Symfony Finder.

How Bob compares to Phing:

• Bob does not use XML config files to define tasks. I think build files should be written in the language used to write the project itself so the barrier to contribution to build files is as low as possible. Also I think it's quite hilarious to use XML for a DSL with logic and such.
• Bob has nothing like plugins. To add new functions to Bob's DSL just put them into the Bob\BuildConfig namespace and require the file somehow at the beginning of your build file. Simply put: Bob's build configs are only PHP.
• Bob has no rich set of provided tasks and I do not plan to add this. Bob is lightweight.

Getting Started

Install

Prerequisites

Bob needs at least PHP 5.3.2 to run.

If you plan to hack on Bob, please make sure you have set phar.readonly to Off in your php.ini. Otherwise you will have a tough luck creating a PHAR package of Bob.

Install into a Composer-enabled Project (recommended)

Add the chh/bob package to the require-dev section in your composer.json:

{
    "require-dev": {
        "chh/bob": "1.0.*@dev"
    }
}

Then run composer install --dev.

You can invoke Bob with:

php vendor/bin/bob

or:

./vendor/bin/bob

System-wide install (Unix-like OS only)

To do a system-wide install, download either a Release or clone the Repository with:

$ git clone git://github.com/CHH/bob.git
$ cd Bob

To install all of Bob's dependencies download Composer and run composer install:

$ wget http://getcomposer.org/composer.phar
php composer.phar install

Then run php bin/bob install and you're done.

By default the bob command is created in /usr/local/bin. To change this set a PREFIX environment variable, the command is then created in $PREFIX/bin.

Prepare your project

You can output a usage message by running

$ php vendor/bin/bob --help

First run in your projects root directory Bob with the --init flag. This creates an empty bob_config.php with one example task:

$ php vendor/bin/bob --init

Bob loads your tasks from a special file named bob_config.php in your project's root directory. Bob also includes all files found in a directory named bob_tasks, in the same directory as your bob_config.php. Files loaded from bob_tasks are treated the same way as regular Bob configs.

It's important that you declare that this file belongs to the Bob\BuildConfig namespace with namespace Bob\BuildConfig;, otherwise the DSL functions are not available.

Hint: It doesn't matter if you're in a sub-directory of your project, Bob will find your bob_config.php by wandering up the directory tree.

Now let's define our first task. This task will output "Hello World":

task('hello', function() {
	println('Hello World');
});

Tasks are run by using their name as argument(s) on the command line:

$ php vendor/bin/bob hello

When Bob is invoked without tasks it tries to invoke the default task.

To set a task as default task assign the task as prerequisite of the default task:

task('default', array('hello'));

You know, tasks should be self-documenting, you really don't want a manual for your build config or do you? Bob provides the desc function for that. Let's add some text to our task, which describes what the task is all about:

desc('Prints Hello World to the Command Line');
task('hello', function() {
	println('Hello World');
});

To view all tasks and their descriptions pass the --tasks flag:

$ php vendor/bin/bob --tasks
bob hello # Prints Hello World to the Command Line

To see more examples for how Bob can be used, simply look into Bob's bob_config.php. It contains all configuration to create Bob's build artifacts, for example the bob.phar and the composer config.

File Tasks

A file task is a special kind of task, which gets only run if either the target (the product of some operation) does not exist, or the prerequisites are newer than the target.

So file tasks are very handy if you've some artifacts which are generated from other files, and which you don't want to regenerate if nothing has changed.

For example: Let's write a task which concatenates three input files to one output file.

First we have to create the prerequisites:

$ echo "foo\n" > file1.txt
$ echo "bar\n" > file2.txt
$ echo "baz\n" > file3.txt

Then put this into your bob_config.php:

fileTask('concat.txt', array('file1.txt', 'file2.txt', 'file3.txt'), function($task) {
    println("Concatenating");
    $concat = '';

    foreach ($task->prerequisites as $file) {
        $concat .= file_get_contents($file);
    }

    @file_put_contents($task->name, $concat);
});

Let's run this task:

$ php vendor/bin/bob concat.txt
Concatenating

This will result in a concat.txt file in your project root:

$ cat concat.txt
foo
bar
baz

Let's run it again, without modifying the prerequisites:

$ php vendor/bin/bob concat.txt

See it? The callback was not run, because the prerequisites were not modified.

Let's verify this:

$ touch file1.txt
$ php vendor/bin/bob concat.txt
Concatenating

The prerequisites of a file task are also resolved as task names, so they can depend on other file tasks too. Or you can put regular task names into the prerequisites, but then you've to be careful to not accidentally treat them as files when looping through all prerequisites.

Packaging tasks for reusability

Ever did write a collection of tasks which you want to put into a package and reuse across projects?

Enter Task Libraries.

All task libraries implement the \Bob\TaskLibraryInterface which defines two methods:

• register(\Bob\Application $app): Is called when the library is registered in the app.
• boot(\Bob\Application $app): is called just before the Bob is run on the command line. Register your tasks here.

Here's a small example which registers a test task which uses PHPUnit:

<?php

use Bob\Application;
use Bob\TaskLibraryInterface;
use Bob\BuildConfig as b;

class TestTasks implements TaskLibraryInterface
{
    function register(Application $app)
    {}

    function boot(Application $app)
    {
        $app->fileTask("phpunit.xml", array("phpunit.dist.xml"), function($task) {
            copy($task->prerequisites->current(), $task->name);
        });

        $app->task("test", array("phpunit.xml"), function($task) {
            b\sh("./vendor/bin/phpunit");

        })->description = "Runs the test suite";
    }
}

You can use task libraries by calling the register function within your build scripts:

<?php

namespace Bob\BuildConfig;

register(new TestTasks);

You will now see the test task when you run ./vendor/bin/bob --tasks.

Hacking on Bob

There are lots of ways to improve Bob, but the most useful for me is to simply submit Issues to the Issue Tracker.

Contributing Code

I'm using the Zend Framework Coding Standard in Bob and so should you when contributing code.

Actually I'm using a loose version of it, the notable differences are:

• I'm treating the public keyword as optional in functions.
• var is okay for defining public instance variables.

Documentation

The Code Documentation is all done with Tomdoc, though there isn't anything generated for now.

Testing

I'm not requiring unit tests for contributions, though functionality which affects the command line tool should be at least tried a couple of times.

This shouldn't prevent you from writing Unit Tests though. I'm using PHPUnit for this purpose. There's also a test task which runs phpunit (this handles the copying the phpunit.dist.xml to phpunit.xml too).

I'm recommending php-build for doing tests with multiple versions of PHP.

Building

When you've done some changes and want to regenerate the bob.phar, simply run Bob on itself:

$ php bin/bob.php

To run only the Test Suite:

$ php bin/bob.php test

(In case you wonder that the PHAR gets sometimes not regenerated: It's only regenerated when the actual source files for the archive change.)