Mass Compile Should Optionally Override Save Version

[smmarlow]

For projects, libraries, and their associated files, if the "Save Version" property is set to an earlier version of LabVIEW, the project and its files are not recompiled to the editor version.  There should be an option on the Mass Compile dialog that allows the "Save Version" property of projects, libraries, and classes to be overridden.

[Christina_R]

Can you please explain what pain point this feature would solve? What is your use case when using the Mass Compile dialog?

[smmarlow]

We have noticed when upgrading all of our systems from LabVIEW 2020 to LabVIEW 2024 that the mass compile tool does not upgrade the project/library/class files, or the VI/control files contained therein, especially when files are set to separate the compiled code.  The mass compiler seems to save the files back in their original version.  The 'pain point' as you call it is extremely slow load times for large applications that have many dependencies.  This is due to the fact that the many files in the dependency hierarchy recompile every time they are loaded.  We ended up having to manually load the lvproj/lvlib/lvclass files and manually edit the "Save Version".  I eventually created a script using VI scripting that modifies this property for all the files in a target folder.  Once this property was updated, a rerun of the Mass Compile tool recompiled and saved all the files in question in version 2024.  The extremely slow load time issue was then resolved.   

By having an option in the mass compiler to override the "Save Version: and mass compile all files in the target folder to the latest version, you will save users the trouble of having to write their own scripts to correct this issue.  We also noticed the mass compiler recompiling some of the same files over and over again, significantly impacting the speed of the mass compile operation.  I suspect it is related to this issue, since the the mass compiler isn't updating the version, the same file will have to be recompiled every time it is loaded as a dependency of another file.  I might be wrong about this, but I suspect that's what is happening.  

[wiebe@CARYA]

>We have noticed when upgrading all of our systems from LabVIEW 2020 to LabVIEW 2024 that the mass compile tool does not upgrade the project/library/class files, or the VI/control files contained therein, especially when files are set to separate the compiled code.  

If the compile code is separated, the VI shouldn't need an upgrade. The compiled code is upgraded, but it's stored in the compile cache so you won't see the upgrade. This seems like the intended and desirable behavior.

If recompilation happens each and every time, we'd need to establish what's going on there. That's certainly an issue.

It seems to me like you're describing a bug... It could be related to the mass compile. Old as it is, it might not be updated to work well with separated compiled code.

[smmarlow]

The behavior we see is that code that is part of a library that has an earlier version setting for "Save Version" property recompiles every time it is opened as part of a project, unless we edit the Save Version property ("Default" for libraries, and "Editor Version" for projects) and resave all the VI's.  We may be wrong, but appears to us that the compile cache does not save to the latest version, hence the recompiling every time the VI's in the library load. 

This is especially evident with 3rd party libraries that are installed to the Program Files directory using the JKI VIPM.  The VIPM mass compiles libraries when installing, but because of this issue, the libs we often use (OpenG, JDP Science, MGI, etc.) recompile every time they are opened, even after mass compiling.  We had to use VI scripting to build our own mass compiler to fix this issue.  The script recursively searches a target folder and sets the "Save Version" of all projects, libraries, and classes to "Editor Version" (projects) or "Default" (libraries, classes), and then loads all the VIs and saves them.  Once we ran this process, the recompiling behavior was fixed and all VI's in our hierarchies now load without the compiling behavior. 

I guess the morale of the story that as nice as the "Save Version" feature is for environments wherein developers are using different versions of LabVIEW, it blocks any automated way to upgrade a code base to the latest version without a lot of manual edits to libraries and projects or the construction of one's own mass compiler using VI scripting.

[wiebe@CARYA]

Still seems like a bug that needs to be fixed to me.

A SSCCE would help, although you're instructions to reproduce are clear.

[Christina_R]

What version of LabVIEW are you using? This sounds like it might be Bug 2816478, which was fixed in LabVIEW 2025 Q1. LabVIEW 2025 Q1 Bug Fixes - NI