Buildfile syntax

The buildfile text may include blank lines and comments. All components are optional, but not all combinations are permitted.

The general format for a buildfile is:

attribute filename contents
attribute filename contents
…

Though the three sections of the buildfile example presented above in “OS Image Buildfiles” seem quite different, in fact they are quite similar. They are all lists of files. Notice also that the buildfile itself is structured:

optional_attributes filename optional_contents

For example, the line [virtual=armle-v7,raw] .boot = { has an attribute of [virtual=armle-v7,raw] and a filename of .boot. The optional_contents part of the line is what we call an inline file.

Note:

In a buildfile, a pound sign (#) indicates a comment; anything between it and the end of the line is ignored. Make sure there's a space between a buildfile command and the pound sign.
For complete information about attributes and modifiers used in buildfiles, see the mkifs documentation in the Utilities Reference.
For information about mkefs buildfiles and their attributes, see “mkefs and its buildfile”, and the entry for mkefs in the Utilities Reference.

Attributes

Two types of attributes can be present in a buildfile:

Boolean ([+attribute] | [-attribute]): Turn on or off a specific attribute. For example, [+attribute] turns on the specified attribute (e.g., [+script]), and [-attribute] turns off the specified attribute (e.g., [-optional]).
Value ([attribute=value]): Assign a value to an attribute type (e.g., [uid=0]). (Note that there are no spaces around the equals sign.)

When combining attributes, put all attributes together inside the square brackets. For example:

Correct: [attr1 attr2]
Wrong: [attr1] [attr2]

In other words, use this syntax: [uid=0 gid=0] file_owned_by_root. The following is incorrect:

# Wrong!
[uid=0] [gid=0] [perms=0666] file1

The above attributes should be combined as follows:

# Correct!
[uid=0 gid=0 perms=0666] file1

Attributes can apply to a single file, or to all files listed after the attribute. For example:

Attributes apply to a single file:

[uid=7] file1_owned_by_user7
[uid=6] file2_owned_by_user6

Attributes apply to all subsequent files:

[uid=7]
file1_owned_by_user7
file2_owned_by_user7

Modifiers

Buildfile modifiers use the same syntax as buildfile attributes (e.g., [some_modifier]), but apply to commands in script files.

In-line files

In-line files are a convenient way to place a file in the image without actually having a file. Instead of getting the contents of this file from the host machine, mkifs gets it from the text enclosed in braces in the buildfile itself.

The following rules apply to in-line files:

You can pick any file name you like, but it's good practice (and kind to those who may come after you) to give the files meaningful names such as .boot or boot, or .script.
The contents of the in-line file can't be on the same line as an opening or closing brace.
Leading spaces count.
To put {, }, or \ characters in the file, preceed each one by by a backslash (\ (e.g., \{, \}, \\).
Filenames that use special characters (not alpha-numeric) must be enclosed in double quotation marks. For example, a file called I "think" so (note the spaces and quotation marks), must be specified:
```
"I \"think\" so" = ...
```