Facilitating Source Control by Separating Compiled Code from VIs and Other File Types

By default, a VI contains two kinds of code: the graphical source code that you edit and a compiled version of this code that LabVIEW uses to run the VI. When you edit the source code of the VI, LabVIEW automatically recompiles the VI to reflect your changes in the compiled version of the code. LabVIEW also automatically recompiles all VIs that call the changed VI, resulting in unsaved changes to the calling VIs. If the calling VIs are stored in source control, these pending unsaved changes force you to check out the VIs when you update their subVIs.

To avoid this problem, LabVIEW allows you to separate compiled code from the graphical source code of a VI, thereby creating source-only VIs. After you separate the compiled code from a VI, LabVIEW still compiles the VI when you modify subVIs. However, LabVIEW stores the recompiled version of the code in a compiled object cache rather than in the VI in source control. Because the VI in source control does not change, you no longer have to check the VI out of source control when you change subVIs.

Determining Whether to Separate Compiled Code from VIs

Separate compiled code from VIs for the following reasons:

To simplify source control�If you separate compiled code from all files within a VI hierarchy or LabVIEW project, changes to one VI do not produce unsaved changes elsewhere in the VI hierarchy. This behavior allows you to check out only the VI you want to modify rather than all the VIs that call the changed VI.
To prepare VIs in source control to be upgraded to a new version of LabVIEW�You can upgrade source-only VIs to a new version of LabVIEW without checking out the VIs from source control.
To improve load time for VIs�LabVIEW can load source-only VIs more quickly than regular VIs. To maximize this benefit, separate compiled code from all the files in a VI hierarchy or project.

Do not separate compiled code from VIs that you intend to load or run using the LabVIEW Run-Time Engine. The Run-Time Engine cannot run source-only VIs because it has no access to the compiled object cache that stores the separate compiled code. If you intend for VI hierarchies that you check into source control to run on the Run-Time Engine, build a source distribution with the VIs.

Facilitating Source Control for Other File Types

LabVIEW also allows you to create source-only project libraries, LabVIEW classes, and XControls that prevent member files from causing unsaved changes in the versions stored in source control. Unlike for source-only VIs, LabVIEW does not actually separate compiled code from these file types, some of which do not even contain compiled code. Instead, when you select the Separate compiled code from source file option for these file types, LabVIEW stores an up-to-date version of each file in the object cache. If you change a member VI of the library, class, or XControl, LabVIEW updates the version of the file in the object cache rather than asking you to save the version that is in source control. Therefore, source-only libraries, classes, and XControls allow all the same benefits as source-only VIs.