Returns arguments that were appended at the end of the command line output

Arguments to appended at the end of the command line output

The default file expression to append to each PathParam in order to build file change prerequisites.

Defaults to ’/**/**/*’

Full name of the sprout tool gem that this tool task will use. For example, the MXMLCTask uses the sprout-flex3sdk-tool at the time of this writing, but will at some point change to use the sprout-flex3sdk-tool. You can combine this value with gem_version in order to specify exactly which gem your tool task is executing.

The path inside the installed gem where an executable can be found. For the MXMLCTask, this value is ‘bin/mxmlc’.

The exact gem version that you would like the ToolTask to execute. By default this value should be nil and will download the latest version of the gem that is available unless there is a version already installed on your system.

This attribute could be an easy way to update your local gem to the latest version without leaving your build file, but it‘s primary purpose is to allow you to specify very specific versions of the tools that your project depends on. This way your team can rest assured that they are all working with the same tools.

An Array of all parameters that have been added to this Tool.

Called after initialize and define, usually subclasses should only override define.

Returns arguments that were prepended in front of the command line output

Arguments to be prepended in front of the command line output

Path where preprocessed files are stored. Defaults to ’.preprocessed‘

Command line arguments to execute preprocessor. The preprocessor execution should accept text via STDIN and return its processed content via STDOUT.

In the following example, the MXMLCTask has been configured to use the C preprocessor (cpp) and place the processed output into a _preprocessed folder, instead of the hidden default folder at .preprocessed.

One side effect of the cpp tool is that it adds 2 carriage returns to the top of any processed files, so we have simply piped its output to the tail command which then strips those carriage returns from all files - which retains accurate line numbers for any compiler error messages.

  mxmlc 'bin/SomeProject.swf' => :corelib do |t|
    t.input                     = 'src/SomeProject.as'
    t.default_size              = '800 600'
    t.preprocessor              = 'cpp -D__DEBUG=true -P - - | tail -c +3'
    t.preprocessed_path         = '_preprocessed'
  end

Any source files found in this example project can now take advantage of any tools, macros or syntax available to CPP. For example, the __DEBUG variable is now defined and can be accessed in ActionScript source code as follows:

  public static const DEBUG:Boolean = __DEBUG;

Any commandline tool identified on this attribute will be provided the content of each file on STDIN and whatever it returns to STDOUT will be written into the preprocessed_path. This means that we can take advantage of the entire posix tool chain by piping inputs and outputs from one tool to another. Whatever the last tool returns will be handed off to the concrete compiler.

Create a string that can be turned into a file that rdoc can parse to describe the customized or generated task using param name, type and description

Create a string that represents this configured tool for shell execution

add_param is the workhorse of the ToolTask. This method is used to add new shell parameters to the task. name is a symbol or string that represents the parameter that you would like to add such as :debug or :source_path. type is usually sent as a Ruby symbol and can be one of the following:

:string

Any string value

:boolean

true or false

:number

Any number

:file

Path to a file

:url

Basic URL

:path

Path to a directory

:files

Collection of files

:paths

Collection of directories

:strings

Collection of arbitrary strings

:urls

Collection of URLs

Be sure to check out the Sprout::TaskParam class to learn more about block editing the parameters.

Once parameters have been added using the add_param method, clients can set and get those parameters from the newly created task.

Alias an existing parameter with another name. For example, the existing parameter :source_path might be given an alias ’-sp’ as follows:

  add_param_alias(:sp, :source_path)

Alias parameters cannot be configured differently from the parameter that they alias

If the provided path contains spaces, wrap it in quotes so that shell tools won‘t choke on the spaces

Iterate over all prerequisites looking for any that are a LibraryTask. Concrete ToolTask implementations should override resolve_library in order to add the library sources or binaries appropriately.

Concrete ToolTasks should override this method and add any dependent libraries appropriately