One of the most useful features of InstallBuilder is the ability to automate the build process. Installers can be built from a command line prompt such as:
installbuilder-6.2.6/bin/builder build /path/to/project.xml linux
The above describes the basic command line build process. You can also make changes to the project prior to the build process to adapt it to your needs using the –setvars flag.
In most cases, this is used to modify project properties such as the <version>, the <fullName> or the <windowsExecutableIcon>:
``` builder build project.xml –setvars version=1.2.3 project.fullName="New Installer Name"
```
However, there is much more you can achieve using this functionality.
Lets assume we have a complete project, including documentation, some optional applications and a lightweight installer that bundles the main project files. The obvious solution would be to have two projects: one that bundles all of the components and the other with the primary project files. This can be achieved by organizing the files and logic into components and using the <include> directive, which allows us to separate them into multiple .xml files.
This approach forces us to repeat some logic, such as the project properties. A more efficient approach would be to have a single XML project file and decide whether or not to pack the components based on the build target. For example, we could use:
builder build project.xml –setvars buildFlavor=full
To build the complete installer and
builder build project.xml –setvars buildFlavor=minimal
to only pack the main application.
For this approach, you simply have to create a hidden parameter to make the buildFlavor type persistent at runtime and use the <shouldPackRuleList>:
``` <project> <shortName>myProject</shortName> <version>1.4</version> … <parameterList> … <stringParameter name="buildFlavor" value="minimal" ask="0"/> … </parameterList> <componentList> <component> <name>main</name> … </component> <component> <name>optionalComponent</name> … <shouldPackRuleList> <compareText text="${buildFlavor}" logic="equals" value="full"/> </shouldPackRuleList> </component> </componentList> </project>
```
You could also combine it with the <preBuildActionList> and customize the particular aspects of the project as in:
``` <preBuildActionList> <actionGroup> <actionList> <setInstallerVariable name="project.fullName" value="Basic Product Installation"/> <setInstallerVariable name="project.windowsExecutableIcon" value="/path/to/minimal.ico"/> <setInstallerVariable name="project.installerFilename" value="minimal-installation.exe"/> </actionList> <ruleList> <compareText text="${buildFlavor}" logic="equals" value="minimal"/> </ruleList> </actionGroup> <actionGroup> <actionList> <setInstallerVariable name="project.fullName" value="Full Product Installation"/> <setInstallerVariable name="project.windowsExecutableIcon" value="/path/to/full.ico"/> <setInstallerVariable name="project.installerFilename" value="full-installation.exe"/> </actionList> <ruleList> <compareText text="${buildFlavor}" logic="equals" value="full"/> </ruleList> </actionGroup> </preBuildActionList>
```
All the above functionality would work if we defined buildFlavor as a regular variable instead of creating a hidden parameter, but we would not be able to access it at runtime in that case. We can use that functionality, for example, to show a link to a download page at the end of installation if the user wants to download optional applications:
``` <finalPageActionList> <launchBrowser url="www.downloads.com/optional" progressText="Would you like to visit our website to download additional modules?"> <ruleList> <compareText text="${buildFlavor}" logic="equals" value="minimal"/> </ruleList> </launchBrowser> </finalPageActionList>
```
Additional information can be found in the links below:
http://support.bitrock.com/article/how-to-set-variables-at-build-time