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.
Two types of attributes can be present in a buildfile:
When combining attributes, put all attributes together inside the square brackets. For example:
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
Buildfile modifiers use the same syntax as buildfile attributes (e.g., [some_modifier]), but apply to commands in script 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:
"I \"think\" so" = ...