Qbs Manual | Rule Item

Qbs 1.9.1

PropertyOptions Item ◦ Scanner Item

# Rule Item

In Qbs, rules create transformers that produce output files from input files. The term transformer refers to a list of commands. These commands are created in a rule's prepare script. They do the actual work, either directly or by executing external commands.

## A Simple Example

The following rule takes text files and replaces Windows-style line endings with their Unix-style counterparts. We will look at it one piece at a time.

      Rule {
          multiplex: false

A multiplex rule creates one transformer that takes all input artifacts with the matching input file tag and creates one or more output artifacts. We are setting the respective property to `false` here, indicating that we want to create one transformer per input file.

Note: This is actually the default, so the above assignment is not required.

      inputs: ["txt_input"]

Here we are specifying that our rule is interested in input files that have the tag "txt_input". Such files could be source files, in which case you would tag them using a Group. Or they could in turn get generated by a different rule, in which case that rule would assign the file tag. The files matching the tag will be available in the prepare script under the name `inputs` (see The inputs and outputs Variables).

      Artifact {
          filePath: input.fileName + ".out"
          fileTags: ["txt_output"]
      }

Here we are specifying that for every input file, we want to create one output file whose name is the same as the input file, but with an additional extension. Because we are giving a relative path, Qbs will prepend that path by the product's build directory.

In addition, we tell Qbs that the output files should get the file tag "txt_output". This enables other rules to use these files as inputs. You must always assign suitable file tags to your output artifacts, or the rule will not be run. See Rules and Product Types for details.

If you want to create more than one output file per input file, you simply provide multiple `Artifact` items. The set of output artifacts will be available in the prepare script under the name `outputs` (see The inputs and outputs Variables).

          prepare: {
              var cmd = new JavaScriptCommand();
              cmd.description = input.fileName + "->" + output.fileName;
              cmd.highlight = "codegen";
              cmd.sourceCode = function() {
                  var file = new TextFile(input.filePath);
                  var content = file.readAll();
                  file.close()
                  content = content.replace(/\r\n/g, "\n");
                  file = new TextFile(output.filePath, TextFile.WriteOnly);
                  file.write(content);
                  file.close();
              }
              return [cmd];
          }
      }

The prepare script shown above puts everything together by creating the command that does the actual transformation of the file contents, employing the help of the TextFile class.

As you can see, the return value is an array, meaning you can provide several commands to implement the rule's functionality. For instance, if we had provided two `Artifact` items, we might have also provided two commands, each of them creating one output file.

For the `input` and `output` variables used in the code, see the next section.

## The `inputs` and `outputs` Variables

We already mentioned that the input and output artifacts are available in the prepare script via the variables `inputs` and `outputs`, respectively. These variables are JavaScript objects whose property keys are file tags and whose property values are lists of objects representing the artifacts matching these tags. In our example, the `inputs` variable has a single property `txt_input`, whose value is a list with one element. Similarly, the `outputs` variable also has one single property `txt_output`, again with a list containing one element.

The actual artifact objects have the following properties:

Property | Description
--- | ---
`baseName` | The file name without any extension.
`completeBaseName` | The file name without the last extension.
`fileName` | The name of the file (that is, `filePath` without any directory components).
`filePath` | The full file path.
`fileTags` | The list of the artifact's file tags.

The artifact object contains a property for every module that is used in the product. That can be used to access the module's properties. For instance, for an artifact in a C++ product, `artifact.cpp.defines` is the list of defines that will be passed when compiling the respective file.

But what about the variables `input` and `output` that appeared in our example? These are simply convenience variables which are available in the case that the `inputs` and `outputs` variables contain only one artifact, respectively. So in our example, instead of `input` we also could have written `inputs.txt_input[0]`, which is considerably more verbose.

## Rules and Product Types

It is important to know that when figuring out which rules to execute, Qbs starts at the product type and then looks for a way to produce artifacts with matching file tags from source files, using a chain of rules that are connected by their respective input and output tags. For instance, consider this simple C++ project:

      Product {
          type: ["application"]
          Depends { name: "cpp" }
          files: ["main.cpp"]
      }

Here's how this product is built:

1. Qbs looks for a rule that can produce artifacts with the file tag `"application"`. Such a rule is found in the `cpp` module (namely, the rule that invokes the linker).
2. Since the rule found in the previous step takes inputs of type `"obj"`, Qbs now looks for a rule that produces artifacts of that type. Again, such a rule is found in the `cpp` module (the rule that runs the compiler).
3. The rule found in the previous step takes inputs of type `"cpp"`. No rule is found that creates such artifacts, but we do have a source file with a matching type (because the `cpp` module contains a FileTagger which attached that type to `"main.cpp"` due to its file extension).
4. Now that there is a chain of rules leading from a source file tag to the product type, the commands of these rules are executed one after the other until we end up with our executable.

## Rule Properties

Property | Type | Default | Description
--- | --- | --- | ---
multiplex | bool | false | Determines whether this is a multiplex rule.
inputs | string list | undefined | File tags the input artifacts must match. All output artifacts will depend on all artifacts in the product with the given input file tags. Also these artifacts are available in the inputs variable of the prepare script.
auxiliaryInputs | string list | undefined | A list of file tags. This rule will be dependent on every other rule that produces artifacts that are compatible with auxiliaryInputs. Unlike inputs, the property auxiliaryInputs has no effect on the content of the inputs variable in the prepare script. All rules in this product and rules of product dependencies that produce target artifacts are considered.
excludedAuxiliaryInputs | string list | undefined | A list of file tags. Connections to rules that produce these file tags are prevented. This property has no effect on the content of the inputs variable in the prepare script.
inputsFromDependencies | string list | undefined | File tags the artifacts of product dependencies must match. For example, the product foo might appear as follows in the current product:
      Depends {
          name: "foo"
      }
All artifacts of foo that match the given file tags will appear in the inputs variable of the prepare script.
outputArtifacts | array of objects | undefined | An array of output artifacts, specified as JavaScript objects. Example:
      outputArtifacts: [{
          filePath: "myfile.cpp",
          fileTags: ["cpp"],
          cpp: { cxxLanguageVersion: "c++11" }
      }]
For a description of the possible properties, see the documentation of the Artifact item. Output artifacts can be specified either by `Rule.outputArtifacts` or by `Artifact` items. Use `Rule.outputArtifacts` if the set of outputs is not fixed but dependent on the input's content. If no file tags are provided, Qbs will apply all file taggers known in the current context to the output file name. The user may set the property `explicitlyDependsOn` on artifact objects, which is similar to `Rule.explicitlyDependsOn`.
outputFileTags | string list | undefined | If output artifacts are specified by `Rule.outputArtifacts`, then `Rule.outputFileTags` must be a list of file tags the rule potentially produces.
condition | bool | true | If true, the rule is enabled, otherwise it does nothing.
explicitlyDependsOn | string list | undefined | Each artifact that matches the file tags in explicitlyDependsOn is added to the dependencies of each output node. All artifacts in the current product and target artifact of products that this product depends on are considered.
prepare | script | undefined | Script that prepares the commands to transform the inputs to outputs. The code in this script is treated as a function with the signature `function(project, product, inputs, outputs, input, output, explicitlyDependsOn)`. The argument `input` is `undefined` if there's more than one input artifact for this rule. Similarly, `output` is only defined if there's exactly one output artifact.
requiresInputs | bool | `true` if the rule declares any inputs, `false` otherwise | Specifies whether a rule's commands should be created even if no inputs are available. Enabling this property can be useful in cases where you potentially have input files, but it is possible that there are none and you want to create the output file in any case.
alwaysRun | bool | false | If true, the rule's commands are always executed, even if all output artifacts are up to date.

PropertyOptions Item ◦ Scanner Item