1. Introduction

1.1. What is Pyke?

Pyke is a build tool that can be used to generate any kind of artifacts in small, medium or large projects.

This tool has the same purpose as make, cmake, ant, maven, scons, jam, ninja, ..., but using a slightly different approach.

Pyke aims to be easy to use, easy to extend, multi-platform and fast! Your job is to create things, Pyke’s job is to make your life easier.

1.2. Why another build tool?

I needed an extremely fast built tool that was really easy to use and extend and was able to generate builds in multiple platforms and multiple languages. I tried some build tools but none of them offered what I was looking for, so... pyke was born as a side-project.

The main goals for pyke are:

• easy to set up for small and big projecs
• easy to extend
• easy to maintain on big projects
• multi platform
• as fast as possible

The aim is to help you improve productivity.

At this point, if you already know what a build tool is, consider skipping the rest of the section and moving to one of the following sections: Pyke’s features or the getting-started or the Quick Start section.

1.3. Why a build tool is useful?

Before starting with the basic concepts, it might be helpful to start asking why a build tool is useful in the first place. If you think about it, a build tool is useful for executing a list of commands in order to build a project in a deterministic way.

Given this basic definition you might be tempted to ask...

1.4. Wouldn’t a shell script do the job?

No way!! Are you crazy? Yes, sure, you can do it. You can use a shell script to automate a build, but most of the times this is a really bad idea.

Here are some of reasons for using a build tool instead of a shell script:

• Automatic dependency checks: In a shell script, all build commands are always executed, but you don’t want to rebuild things that have already been built in previous iterations and that have not changed at all, you only want to build the things for the files you modified since the last build.
• Smaller and simple build files : You usually don’t want to be writing the same commandline once and once again for each file that needs to be built. Also, if at some point in time you want to change how things are built, like change compiler, or flags or something like that, with a build tool you will only have to change it in one place.
• Fast parallel builds: You might realize that nowadays computers have multiple processors, so running things in parallel will speed up things. Doing parallel builds with shell scripts is to say the least, impractical. Try it if you want to have some fun :p
• Multiplatform: This is not always a requirement, but imagine you write a shell script that works perfectly well on your machine, and now you want to compile everything in another operating system, assuming your code is portable... if you work on windows and want to compile on mac or linux you’ll ned to port your batch script to a shell script or vice versa!! The bigger the project, the more painful it is. Using a build tool you will only need to create a new set of rules for the new OS or architecture.

Using a build tool is always the right choice if you need a deterministic way of creating some deliverables for your project, either personal, open source or commercial.

Usually build tools are used when you have to compile files or build applications, but you will also benefit from a build tool even if you are creating a web site. For example, in the case of a website, it might handle CSS/JS compression, unit tests, creating an artifact, and even deploying it to production server.

Just to give an example, let’s say you have a really simple C++ project with the following structure:

+ project/
  + src/
    - main.cc
    - file.cc
    - string.cc
  + inc/
    - file.h
    - string.h

Imagine you want to generate the executable ‘app’ under ‘bin’ folder from this set of files.

Using a shell script and compiling with GCC you would write something like this:

mkdir out/
g++ -c -o out/main.o -Iinc/  main.cc
g++ -c -o out/file.o -Iinc/  file.cc
g++ -c -o out/string.o -Iinc/ string.cc

mkdir bin/
g++ -o bin/app out/*.o

Now, every time you run this script, it will run all the commands, even if no files have changed. Compare that script with the equivalent pyke file:

from pyke.tools.default import *

objects = cc ('src/*.cc', include = 'inc/')
app ('bin/app', objects)

Keep in mind that the pyke file only builds things once (when the sources or header files have been modified) and parallelizes all the commands whenever possible. It automatically detects dependencies so it can parallelize everything automatically, without you having to figure out how to do it. Even more, if the code is portable, it will be able to compile in Linux, Mac OS or Windows without touching a single line.