Builder HowTo

This page is the first in a series of HowTo's regarding OpenG tools. This one focuses on distributing software to third party users using OpenG builder

The basic idea's for distributing my code in this way are basically the following:


 * For a user it should be easy to use my code
 * For a user upgrading should be easy
 * For the developer (me) distributing the code should be easy
 * For the developer, generating a new distribution should be easy
 * For the developer I shouldn't have to worry about mixing up development code and production code

All of these Items can be addressed using OpenG tools. I will focus on OpenG builder and Packager and how they can ease the distributing workflow.

OpenG builder


OpenG builder is a tool to copy LabVIEW code and build Executables. Originally it was a tool for advanced save as routines in LabVIEW. Let's have a look at the tool.

After starting the tool the following GUI is shown:



Let's go over the several fields:


 * Project Root
 * This field represents the root folder of the project, it should contain the source as build files as well.


 * Source Root
 * This field represents the source folder of the project, it should contain all the source files of any build.


 * Build Root
 * This field represents the folder were the results of the build will be stored.

Namespacing

 * Namespace (convention)
 * Namespacing is very important when you use your own code, it keeps a clear seperation between development code and distribution code. If you don't namespace your code you can easily get into trouble, for instance you could get crosslinks with development code or with other toolkits (search you harddrive for init.vi. for instance). The actual namespace can be disabled (none), be supplied by the developer (custom) or supplied by OpenG builder (random). OpenG builder has support for three kinds of namespacing.
 * suffix (OpenG type)
 * This namespace convention adds to every file name a double underscore followed by the actual namespace. This way you can still easily see the source filename. This namespace convention is used for all OpenG toolkit VIs.
 * prefix (exact)
 * This namespace convention adds an exact string to the beginning of the filename, you can easily identify all the files belonging to a single toolkit.
 * prefix with space
 * This namespace adds a namespace string followed by a space to the beginning of the filename, this seperates the toolkitname from the filename in a clear way.


 * Log file...
 * This will display a log-file options dialog.


 * Version...
 * This will display a Version options dialog.


 * Plug In VIs...
 * This will display s PlugIn VIs options dialog.


 * Overwrite existing files
 * This option will toggle the behaviour when files allready exist.


 * Backup build root dir
 * This option will instruct OpenG builder to create a backup-copy of the Build root before starting to build.


 * Message box if there is a VI with unsave changes
 * This option will instruct OpenG builder to inform you if there are VIs with unsaved changes.

Version VIs
This will launch the version dialog:



This dialog is used to master the version settings of the distribution.

The following fields are available:


 * Revision file
 * This file contains the info used by OpenG builder to store the version of the distribution. With the Find button you can browse your distribution for the version control file. With the New button a new version control file will be generated. It's an INI file with for every distribution a group (several distributions can share a single revision file) with the following key-value pairs.
 * Version
 * The version of the last build, it consists of three levels: Main, Minor and fix
 * Build number
 * This integer is automatically raised on every build.
 * Status
 * This boolean flag indicates if the build succeeded without errors.
 * Warnings
 * This integer lists the number of non-fatal warnings during the build.
 * Log-file
 * This path points to the log file of the build.


 * Version VI name
 * This file is the VI where OpenG builder will store the version info inside the distribution. The VI should be part of your distribution.


 * Version control name
 * This string contains the caption of the control on the Version VI where OpenG builder will store the version info of the distribution. The cluster of the control should be compatible to the typedef Version Info Cluser__ogb_api.ctl from the OpenG api palette. The cluster is of the following type:


 * Version as String
 * Build number as Unsigned DWord (U32)
 * Build date as Float64 (DBL)

Upon building OpenG builder will update the control inside the distribution and store the version info as the default value of the distribution. You can use this to retrieve the version of the distribution inside the distribution.

Source VIs
It is best to have one or two VIs that contain all the VIs belonging to the distribution, this can be a main VI or even better a Tree VI.

You can add these VIs on the Source VIs tab page.



You can define two types of VIs, Top level and Dynamic, normally Top level is OK.