For those of you using source code control (I hope that’s everyone reading this), you may have run into this situation before: You make a simple, seemingly trivial change to one your VIs, and then LabVIEW starts asking you to re-save a dozen other VIs you didn’t touch. Although this may befuddle you, it may go unnoticed for the majority of you reading this. However, if you have to justify, track or even validate any and all changes to your source code, this can be extremely frustrating. In addition to the fact that you have to check-in ‘modified’ VIs that you didn’t touch, this may raise some red-flags in a regulated environment, especially if someone else insists on examining your changes.
So first off, why does this happen? Unlike other programming languages, the VI file format not only contains the source code, it also contains the compiled code (also referred to as object code). For the vast majority of LabVIEW users, this simplifies application management and avoids having to keep track of the compiled code separately. However, one simple change may cause LabVIEW to recompile other parts of your application – this can be attributed to optimization routines and the propagation of datatypes. When this happens, the new object code is saved into the respective VIs, which have then been modified by LabVIEW, even though the source code hasn’t changed.
LabVIEW 2010 introduced a new capability to address this problem. You can now remove the object code from VIs and store them separately on disk. As a result, the only thing that can cause a change to a VI is the modification of source code, which is what anyone from a text-based background would expect.
The LabVIEW 2010 Help documents how to turn this on for a VI or even the contents of a Project file, but we’ve had several requests from users to enable this feature by default so that any and all new VIs are saved as ‘source-only’ VIs. Thankfully, this can be done using an ini token: SourceOnlyEnvironment=True. As with any ‘secret’ ini token, it’s not supported and it’s considered experimental. One side affect to be wary of is that you cannot create a normal ‘uni-file’ with this setting enabled (the VI Property setting is ignored), which is required for dynamically loaded VIs.
UPDATE: Many people have asked why this isn’t just on by default in 2010. The original plan was that it would be on by default, but benchmarks showed that the operation required to check the cache of object files ‘mod date’ slowed down load time to the point that we were not comfortable turning it on for everyone. We also weighed the ramifications for people who were calling VIs directly from a built executables (not a recommended practice, by the way). Because the RTE does not have a compiler, the executable would not be able to create the object files for source-only VIs and would not be able to run source-only VIs. As a result, you either have to build VIs into something that includes the object files, or include them with the executable when it’s built. If this affects you, consider packaging your VIs as packed project libraries (new in 2010), DLLs, separate executables or including them in the main executable. Before you protest, consider the fact that you would never call a .C file directly from an EXE.
Anyway, R&D has been hard at work looking for ways to address the problems we saw with load time and they’ve come across some very promising solutions using databases. Without making any guarantees, I strongly encourage everyone to assume that this feature will be the only available option for future versions of LabVIEW. The bottom line, is that if you have applications you’ll know you’ll be upgrading to 2011 and beyond, turn this setting on sooner, rather than later.
– Elijah Kerry