Can LabVIEW build specifications produce repeatable outputs when VIs are saved with compiled code separated from source?
0 reputation · 25 Sept 2023, 21:24 UTC
A team is standardizing a repeatable build pipeline for a LabVIEW application and wants the same tagged source to rebuild predictably on different workstations running the same LabVIEW version and modules. The project includes VIs saved with compiled code separated from source, and the .lvproj uses auto-populating folders alongside absolute driver references. Because LabVIEW files are binary and build outputs can embed environment-specific metadata, the team cannot assume two clean checkouts will produce identical installers or even identical load-time behavior. They also need to understand whether the separated compiled-code save state changes what source control actually protects during a rebuild.
Before committing to a workflow, they need to resolve how much of the build environment must be frozen. Does saving VIs with compiled code separated from source make cross-workstation builds more deterministic than embedding compiled code, or does it simply shift the variability into load-time prompts? Which elements of the .lvproj and build specification are most likely to introduce machine-specific drift despite a clean checkout? How can the team verify functional equivalence when bit-for-bit reproducibility is not expected?