This chapter continues from where The command line interface and bootstrapping left us.

Creating the workspace definition

After defining the iwant revision to use, the wizard requested us to describe the workspace by editing a configuration file it created. We'll do so now. We name our workspace "iwant-tutorial" and we also define a fully qualified name for the class that defines the entrypoint to our own build code, the workspace definition definition.

It is advisable to follow the convention of naming the last part of the workspace definition definition package "wsdefdef". It will help iwant to generate a good workspace definition name in the next phase.

We make another wish for help to continue.

Now we have a functional workspace definition, also known as a build script, for our workspace.

As we can see from the output, there is at least one new wish available for us, the side-effect of creating eclipse settings. iwant maintains a bash script, a wish script for each wish defined in the workspace definition. This makes it very convenient to make wishes by using tab.

Let's find out what wish scripts we have.

It is advisable to ignore the wish scripts (except for help.sh, the iwant cli) from the version control, since iwant regenerates them at every wish, according to the workspace definition.

Optional: configuring the worker thread count

In this tutorial we'll use only one worker thread to keep the output deterministic. You should probably use a bigger number, depending on your machine. You'll probably want to skip this phase and use the default value, the number of cores in your system:

Finishing with the wizard

Let's end the wizard by wishing for help one more time.