Featureless Make Fakefile Specification

This describes intent and purposes of the fakefile file settings.

All files specified are relative to the project root.

The reserved Section Names are defined as follows:

• settings:

  Any configuration specific to this fakefile is stored here.

  This includes the declaration of define and parameter IKI variable substitution values.

  If multiple Objects of the same name exist and that Object only supports a single value, then only the Content from the last same named Object is used.

  The build settings may also be specified in the Settings Section.

  The following settings are available (in addition to the build settings):

  • compiler:
    • This represents the name of the compiler program to use, such as gcc.

      The programs gcc and clang are known to work.

      Many of the parameters in the settings file can be changed if using a non-GCC, but there may be certain hard-coded functionality that may need to be changed.

      When specified and load_build is true, then this will override the build_compiler specified in the loaded build settings.

  • define:
    • This represents an environment variable to define on run.

      The environment variable name is case-sensitive.

      This replaces the value of any existing environment variable with this name.

  • environment:
    • This represents all environment variables that are exposed when executing sub-programs.

      This is not auto-populated for environment variables defined in the define setting.

      When defined with no Content, then this means that no environment variables are exposed.

      When not defined at all, then all environment variables are exposed.

      Environment variables may still be exposed if load_build is true and the build setting file defines any environment variable names.

  • fail:
    • Designates the fail mode when running external programs, such as through the run or shell operations.

      There are three options:

      1. exit: Designates to exit the program on failure, printing an error message.
      2. warn: Designates to continue on and if in verbose mode then print a warning.
      3. ignore: Designates to do nothing.

      The return code for programs can still be retrieved through using the reserved IKI vaiable return.

  • indexer:
    • This represents the name of the indexer program to use, such as ar.

      An indexer is often called a linker.

      Similar to build_compiler, any linker that supports the ar program parameters is effectively supported.

      When specified and load_build is true, then this will override the build_indexer specified in the loaded build settings.

  • indexer_arguments:
    • This represents arguments needed to build an archive file from object files, such as rcs.

      These arguments are placed immediately before the object files passed to the indexer program.

  • load_build:
    • This represents whether or not to load the load the build settings file.

      The first Content value may be true to load the build settings and false to not load the build settings file.

  • parameter:
    • This defines an IKI variable name to substitute with the value.

      This replaces the value of any existing environment variable with this name.

      The first Content value represents the IKI variable name.

      All Content values after the first represent the values the matching IKI variable is replaced with.

      The parameter variable name return is used to store the return result of a run or shell operation.

      Setting this here only sets the default return parameter variable value.

  • stage:
    • This defines a name that is added to the build stage files to help uniquely identify build stages associated with this file.

      This name must only have valid characters for a particular file system.

      The variables allowed are different from file system to file system and so special characters should generally be avoided.

      To help prevent problems with paths, slashes (forward slash and backward slash) are not allowed in the stage name.

• main:

  This is the main entry point when processing the fakefile.

  This is processed top-down until the end of the list is reached.

  The following operations are available:

  • and:

    A special type of an if operation.

    May only be specified following a valid if, and, or or operation.

    This is executed only if the previous if operation result is true.

    When executed, this performs the test and returns true or false as appropriate.

    When not executed, this passes through the result of the previous if, and, or or operation.

  • build:

    Run the fake build operation as if fake build was run instead of fake make.

    Command line arguments are automatically passed to the fake build operation.

    Accepts an optional Content that is a file name to a build settings file to use instead of the default.

    This file name is relative to the data build directory (which can be changed by -D/--data parameter).

    If the optional file name Content is specified, then it also supports additional modes to use instead of the default mode.

    When no additional Content after the build is specified, then the default (or program supplied) settings file and modes are used.

    When the first Content after the build is specified as an empty string, then the default (or program supplied) settings file is used.

    When the second Content after the build (and there is no third Content), then no modes are used.

  • break:

    Perform an exit from the current make operation.

    This only exists the current depth.

    If the depth is at the top (aka: 0), then this is identical to the exit section operation.

    The second Content may be either 'succeed' or 'fail' to designate on whether or not to exit as success or failure.

    When set to failure this will trigger any failure (with message), depending on the current fail state.

  • clean:

    Run the fake clean operation as if fake clean was run instead of fake make.

    Command line arguments are automatically passed to the fake build operation.

  • clone:

    Copy all files (and directories), preserving all properties, into the last content.

    If there are more than one file (or directory) being copied, then the final path must be a directory.

    All Content, except last, represents the files to clone.

    The last Content represents the destination file (or directory) to clone to.

  • compile:

    Execute the compiler program, such as gcc.

    All Content are passed as arguments to the respective gcc program.

  • copy:

    Copy all files (and directories) into the last content.

    If there are more than one file (or directory) being copied, then the final path must be a directory.

    All Content, except last, represents the files to copy.

    The last Content represents the destination file (or directory) to copy to.

  • define:

    This represents an environment variable to define on run.

    The environment variable name is case-sensitive.

    This replaces the value of any existing environment variable with this name.

  • delete:

    Delete one or more files or directories.

    All Content must be the file or directory to be deleted.

    If the path is a directory and is not empty, then this will not delete the directory.

  • deletes:

    Identical to delete, except that when the path is a directory and is not empty, then this will delete the directory.

  • else:

    Performs a programmatic else condition.

    Must be specified following a valid if operation (and the operation it affects).

    This has no Content.

    An else operation may not follow this.

    An if operation may immediately follow to represent an else if condition.

  • exit:

    Perform an exit from the entire make operation.

    This always exits completely, regardless of the operation depth.

    The second Content may be either 'success' or 'failure' to designate on whether or not to exit as success or failure.

    When set to failure this will trigger a failure message.

    When set to failure, the fail state will be forcibly changed to fail regardless of the current fail state.

  • fail:

    Toggle how the to handle an operation failure.

    The first Content may be one of the following:

    • exit: Set failure handler to exit on failure.
    • warn: Set failure handler to print a warning on failure but continue on.
    • ignore: Set failure handler to continue on regardless of failure.
  • group:

    Change the group role for a given file.

    The first Content represents the group to assign.

    The second Content represents the file to assign the group to.

  • groups:

    Identical to group operation, except this will recursively apply the mode to all files within the given file, if that file is a directory file path.

  • if:

    Performs a programmatic if condition.

    May be specified following a valid else operation.

    The Content represents a set of conditions to perform.

    The if operation may be used in conjunction with the and, or, and the else operations.

    The conditional logic is different from normal logic found in most software programs.

    There is only one order of operation, a top-down design where the current operation relates to the previous operation.

    This is mostly relevant when if operation is followed by an and or an or operation.

    Consider the following:

    if parameter xxx
    or parameter yyy
    and parameter zzz
      print first
    else
    if parameter www
      print second
    else
      print third
    

    The resulting logic is as follows:

    1. If xxx is defined, then...
    2. If result from (1) is TRUE or if yyy is defined, then...
    3. If result from (2) is TRUE and if zzz is defined, then...
    4. If result from (3) is FALSE, then...
    5. If result from (4) is TRUE, then...
    6. If result from (5) is FALSE, then...

    For all conditions that rely on numbers, only whole numbers are (currently) supported.

    conditions:

    • == "left" "right":

      Compare all parameters to be equal.

      Requires 2 or more after the ==.

      For example, if == 'a' 'b' 'c' 'd' would test: 'a' == 'b' && 'b' == 'c' && 'c' == 'd'.

      This performs only string-based comparisons.

    • > "left string" "right string":

      Compare left to right for greater than.

      Requires 2 or more after the >.

      For example, if > 0 1 2 3 would test: 0 > 1 && 1 > 2 && 2 > 3.

      This performs only number-based comparisons.

    • < "left string" "right string":

      Compare left to right for less than.

      Requires 2 or more after the >.

      For example, if < 0 1 2 3 would test: 0 < 1 && 1 < 2 && 2 < 3.

      This performs only number-based comparisons.

    • >= "left string" "right string":

      Compare left to right for greater than or equal to.

      Requires 2 or more after the >=.

      For example, if >= 0 1 2 3 would test: 0 >= 1 && 1 >= 2 && 2 >= 3.

      This performs only number-based comparisons.

    • <= "left string" "right string":

      Compare left to right for less than or equal to.

      Requires 2 or more after the >=.

      For example, if <= 0 1 2 3 would test: 0 <= 1 && 1 <= 2 && 2 <= 3.

      This performs only number-based comparisons.

    • <> "left" "right":

      Compare all parameters to be not equal.

      Requires 2 or more after the ==.

      For example, if <> 'a' 'b' 'c' would test: 'a' <> 'b' && 'b' <> 'c' && 'a' <> 'c'.

      This performs only string-based comparisons.

    • define "some define name":

      Test if one or more names are defined as an environment variable.

      For example, if define PWD SHELL would test if both the PWD and the SHELL variables are defined via the environment variables.

    • exist "file path":

      Test if file exists.

      For example, if exist "a.txt" "b.txt" would test if both the file a.txt and b.txt exist.

    • failure:

      Test if the previous section operation failed.

    • group "some mode" "some file":

      For example, if group friends a.txt b.txt would test if both file a.txt and b.txt have a group named we.

    • is block character directory fifo link regular socket for "file path":

      Test if one or more files exist and if each file is any of the given types.

      The given types must be followed by for to designate where the the file paths begin.

      For example, if is regular directory for "a.txt" "b.txt" would test if both the file a.txt and b.txt exist and are either of type regular or type directory.

    • mode is/has "some mode" "some file":

      Test if one or more files has the exact mode (is) or has at least the given modes (has).

      For example, if mode is u+r a.txt b.txt would test if both file a.txt and b.txt only have owner set to read.

      For example, if mode has u+r a.txt b.txt would test if both file a.txt and b.txt has owner set to read, and all other modes can be anything.

    • not:

      Perform the test expecting a false result rather than a true result.

      This is to be immediately followed by a valid if condition as well as all appropriate valid content associated with that if condition.

      Only the following if conditions are supported:

      • define.
      • exist.
      • group.
      • is.
      • mode.
      • owner.
      • parameter.

      Examples:

      • if not parameter work
      • if not exist documentation.txt
    • owner "some mode" "some file":

      Test if one or more files has the given owner.

      For example, if owner me a.txt b.txt would test if both file a.txt and b.txt have an owner named me.

    • parameter "some parameter name":

      Test if one or more names are defined as a parameter variable.

      For example, if parameter verbose silent would test if both the verbose and the silent variables are defined via the parameter setting.

      Reserved parameters that represent program arguments, three forms are available.

      For example, the program argument -w/--work has the reserved word work and has three forms:

      1. work.
      2. work:option.
      3. work:value.

      In the case of form 1, the if parameter work would be true if the argument is passed to the program or a default is provided.

      In the case of form 2, the if parameter work:option would be true if the argument is passed to the program.

      In the case of form 3, the if parameter work:value would be true if the argument is passed to the program and has a non-zero value.

      Some reserved parameters, such as the verbosity, has no value and in this case would always return false for if parameter verbosity:value.

      The following are reserved parameters:

      • build: Associated with -b/--build parameter.
      • color: Associated with +d/++dark, +l/++light, and +n/++no_color parameters.
      • current: The absolute path to the current working directory (present working directory) (Always has a trailing forward slash).
      • data: Associated with -D/--data parameter.
      • define: Associated with -d/--define parameter.
      • fakefile: Associated with -f/--fakefile parameter.
      • mode: Associated with -m/--mode parameter and possibly with the build settings default mode modes_default.
      • process: Associated with -p/--process parameter.
      • return: Contains the return value of a previous operation that produces a return code.
      • settings: Associated with -s/--settings parameter.
      • sources: Associated with -S/--sources parameter.
      • top: The absolute path to the top directory, which is the base project directory (Always has a trailing forward slash).
      • verbosity: Associated with +Q/++quiet, +E/++error, +N/++normal, +V/++verbose, and +D/++debug parameters.
      • work: Associated with -w/--work parameter.
    • succeed:
      • Test if the previous section operation succeeded.
  • index:

    Execute the linker program, such as ar.

    All Content are passed as arguments to the respective ar program.

  • link:

    Create a symbolic link from some point to some target.

    The first Content, when there are more than 2 arguments, may be either force or strict.

    The second to last Content represents the target file.

    The last Content represents the point file.

    The force Content designates that the point file will be overwritten if the file already exists.

    The strict Content requires that the target file already exists.

  • mode:

    Change the mode permissions for a given file.

    The first Content represents the mode to assign.

    The second Content represents the file to assign the mode to.

  • modes:

    Identical to mode operation, except this will recursively apply the mode to all files within the given file, if that file is a directory file path.

  • move:

    Move all files (and directories) into the last content.

    If there are more than one file (or directory) being copied, then the final path must be a directory.

    All Content, except last, represents the files to move.

    The last Content represents the destination file (or directory) to move to.

  • operate:

    Begin execution of another Section.

    The first Content represents the name of the Section Object to execute.

    This may be neither the settings Section no the main Section.

    Recursion is prohibited, a Section that is already on the operation stack may not be called again.

    Once the operation is off the stack, it can then be called again.

  • or:

    A special type of an if operation.

    May only be specified following a valid if, and, or or operation.

    This is executed only if the previous if operation result is false.

    When executed, this performs the test and returns true or false as appropriate.

    When not executed, this passes through the result of the previous if, and, or or operation.

  • owner:

    Change the owner role for a given file.

    The first Content represents the role to assign.

    The second Content represents the file to assign the role to.

  • owners:

    Identical to owner operation, except this will recursively apply the mode to all files within the given file, if that file is a directory file path.

  • parameter:

    This represents a variable defined within the scope of the fakefile.

    This is not exported as an environment variable and is therefore not visible to any executed programs or scripts.

    This replaces the value of any existing parameter variable with this name.

    The reserved parameter variable names (see IKI vocabulary context section below) may not be changed by this.

  • pop:

    Pop a directory path of the path stack, thereby changing to the previous directory on the stack.

    This is a change directory command similar to a back button in a browser.

    This has no Content.

    This does not generate an error if the path stack is empty.

    If the directory popping to no longer exists, then an error occurs.

  • print:

    Print the content to the output screen.

    This always prints a newline at the end.

    All Content is printed, and if no Content is provided, an empty line is printed.

    The following escape sequences are supported for printing special characters:

    • \f: Form Feed.
    • \n: New Line.
    • \r: Carriage Return.
    • \t: Tab.
    • \v: Vertical Tab.
    • \: Backslash Character (may require additional slashes in certain circumstances.)
    • \0: NULL Character.
    • \U+: Unicode Sequence (followed by a valid Unicode sequence with a minimum 4 hexidecimal digits and a maximum of 6 hexidecimal digits).
    • \!: Non-printing separator, allowing for \U+000A\!5 to be equivalent to \n5.

    If the Unicode is invalid, then nothing is printed for that character (the invalid character is skipped when printing).

    Example Unicodes:

    • \U+000A: Prints a new line, equivalent to \n.
    • \U+2E19: Prints the Unicode feather-like character ⸙.

    Only ASCII alpha-numeric hexidecimal digits are allowed in the Unicode sequence (upper or lower case).

    Invalid or unknown escape sequences are not printed.

  • run:

    Manually execute a remote program or script.

    This program must be in the appropriate PATH environment or otherwise automatically detected when calling without a specific path to the program or script.

    The first Content represents the program or script name.

    All Content after the first are passed to the program or script when running.

    After this executes the return result is made available via the return parameter variable name.

    Any existing value associated with return gets replaced.

  • shell:

    Manually execute a remote program or script using a specific path to the program or script.

    This does not require the program to exist in PATH, but the path to the program or script must be relative to the project path.

    The first Content represents the program or script name.

    All Content after the first are passed to the program or script when running.

    After this executes the return result is made available via the return parameter variable name.

    Any existing value associated with return gets replaced.

  • skeleton:

    Run the fake skeleton operation as if fake skeleton was run instead of fake make.

    Command line arguments are automatically passed to the fake skeleton operation.

  • to:

    Change to the directory within the project root path tree, pushing the previous directory onto the path stack.

    The previous path is saved onto the path stack and may later be popped off.

    The first Content represents the path to change directory into.

  • top:

    Change to the project root path, clearing the directory path stack.

    This has no Content.

    If the project root path no longer exists, then an error occurs.

  • touch:

    Manually create a new file or a directory within the project root or update its last changed timestamp if the file already exists.

    The first Content must be either file or directory.

    The remaining Content must be a path to the file.

  • write:

    Write strings to a file within the project root.

    The Content after the first Content is appended to the file.

    The first Content represents the file to write to.

    If there is no Content beyond the first, then the file is truncated (all content within the file is deleted).

    In all cases, if the file does not exist, the file is created.

    When only the first Content exists, this acts similar to the touch operation.

    The major difference between the two is that the touch operation does not alter the content within the file.

    This does alter the content within the file.

    A single space is printed between each argument.

    To preserve spaces, wrap the message in quotes (single or double).

    The following escape sequences are supported for printing special characters:

    • \f: Form Feed.
    • \n: New Line.
    • \r: Carriage Return.
    • \t: Tab.
    • \v: Vertical Tab.
    • \: Backslash Character (may require additional slashes in certain circumstances.)
    • \0: NULL Character.
    • \U+: Unicode Sequence (followed by a valid Unicode sequence with a minimum 4 hexidecimal digits and a maximum of 6 hexidecimal digits).
    • \!: Non-printing separator, allowing for \U+000A\!5 to be equivalent to \n5.

    If the Unicode is invalid, then nothing is printed for that character (the invalid character is skipped when printing).

    Example Unicodes:

    • \U+000A: Prints a new line, equivalent to \n.
    • \U+2E19: Prints the Unicode feather-like character ⸙.

    Only ASCII alpha-numeric hexidecimal digits are allowed in the Unicode sequence (upper or lower case).

    Invalid or unknown escape sequences are not printed.

  The IKI vocabulary context is supported and is further clarified as follows:

  • context:
    • The context Object represents a name representing simple context or complex combination of context.

      Context should wrap some text such that if some text begins with some context, the context should be reset at the end.

      The most basic context is color context, such as: context:"notice" This is emphasized text context:"reset".

      The use of IKI in this way is acceptable but it is not perfect.

      IKI is not designed to be a replacement to markup.

      The markup <strong>Example</strong> vs the IKI context:"notable" Example context:"notable" has obvious differences in the spaces.

      The IKI by design cannot be used like this: context:"notable"Examplecontext:"notable" because the word Example and the word context collide.

      This context will respect the programs ++light, ++dark, and ++no_color parameters.

      The following context are available:

      • error: Designate as an error, often printed in red.
      • important: Designate as important.
      • normal: Explicitly designate normal text.
      • notable: Designate as notable (similar to strong or bold in HTML).
      • reset: Remove the context.
      • standout: Designate to make notable (similar to italic or emphasis in HTML).
      • success: Designate as a success, often printed in bright green.
      • title: Designate as a title.
      • warning: Designate as a warning, often printed in some shade of orange.
  • define:

    The define Object represents environment variables passed to the program or created by the program.

    The value represents the environment variable name and is case-sensitive.

    This IKI variable gets substituted with the environment variable's value or NULL if not defined.

    The settings list supports declaring custom environment variables (which overwrite any existing environment variable with the same name).

  • parameter:

    The parameter Object represents a variable that is to be substituted.

    The value represents the variable name and is case-sensitive.

    This IKI variable gets substituted with the value defined in the settings list or NULL if not defined.

    The value may contain an additional :option or :value at the end of the name to designate getting only part of the parameter.

    The following are reserved parameter variable names:

    • build:

      This variable holds the build program parameters, such as -b build/.

      This supports both :option and :value.

    • color:

      This variable holds the color related program parameters, such as +n.

      This supports both :option and :value (value is always an empty string).

    • data:

      This variable holds the data program parameters, such as -D data/.

      This supports both :option and :value.

    • define:

      This variable holds the data program parameters, such as -d define/.

      This supports both :option and :value.

    • fakefile:

      This variable holds the fakefile program parameters, such as -f fakefile.

      This supports both :option and :value.

    • mode:

      This variable holds the fakefile program parameters, such as -m monolithic.

      This supports both :option and :value.

    • process:

      This variable holds the process program parameters, such as -p process_name.

      This supports both :option and :value.

    • return:

      This variable holds the return status from a previously run user-space applications, which happens with the run and shell section operations.

      This does not represent the return code for each line, just only those lines that run user-space applications.

    • settings:

      This variable holds the settings program parameters, such as -s settings.

      This supports both :option and :value.

    • sources:

      This variable holds the data program parameters, such as -S sources/.

      This supports both :option and :value.

    • verbosity:

      This variable holds the verbosity related program parameters, such as +V.

      This supports both :option and :value (value is always an empty string).

    • work:

      This variable holds the work program parameters, such as -w work/.

      This supports both :option and :value.

      An example of getting just the :option or :value part of a parameter for the work parameters:

      • work:option:

        This variable holds the option part of the work program parameters, such as -w.

      • work:value:

        This variable holds the value part of the work program parameters, such as work/.

  The Content no_dereference may be specified in certain cases relating to files.
  These cases operate on a file that can be a link itself or the link target.
  The default behavior is normally to dereference the link target.

  For example, consider a symbolic link, called some_file, that points to a file that does not exist (which means that the link in question is a broken link).
  The Operation if exist some_file would return false.
  The Operation if no_dereference exist some_file would return true.
  This is because the symbolic link itself, some_file, does exist but the file it is pointing to does not.
  The no_dereference is ignored for conditions that do not need it.