LabVIEW Idea Exchange

cancel
Showing results for 
Search instead for 
Did you mean: 
Yamaeda

Abortable recompile when closing project

Status: New

If you e.g. open a project in a newer LV and then close it; it starts recompiling everything with no abort option, and only after having recompiled 2000 VI's i can choose to _not_ save them ...

I just opened it to check a few things and ended up with Kill Process to get out of it.

 

Let us cancel/abort the recompile when shutting down.

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
6 Comments
Yamaeda
Proven Zealot

*Abortable! 

Damnit 🙂

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer
Mads
Active Participant

The implementation of being able to work across LabVIEW versions has quite a few quirks like these...I think most people expected it to be a very transparent/Invisible background function (as if the newer version actually worked as if it was the older version when opening projects, and vice versa: by eliminating the need to convert back to previous versions with all the issues that often has) ...but instead it sticks its head out and asks for recompiles, saves etc.


If you actually set the project to be in the current editor version this issue will for the most part go away...Some libraries might still be set to stay in a previous version and you have to open the library and set it to be in the current verison instead to avoid constant recompile and saves...If you then want to work on it in an older version you can set the project version to that and save...(or was that how I thought it would work but it does not...I keep getting surprised by that still).


thols
Active Participant

I always wondered why it needs to compile at all when closing

Certified LabVIEW Architect
fefepeto_kb
Member

If I take a step back, then I would question what is the problem the compilation when opening the project or saving VIs solves.

I think, that having an up to date linking between the pieces of the code is very valuable, but having the application compiled all the time might not be necessary. I mean, if we compare it with text based languages, they don't even process the code until someone starts a debug run or a release build. (Well, I just realized that even Visual Studio started adding in options for near real time compile error check which might be valuable feedback during edit time too.)

But the main problem is the way the LabVIEW compiler is written, as I learned from the developers: it is a monolithic code which is very old, and nobody understands it to an extent that they would dare to refactor it. I think the potential values are quite compelling: separating the linker which would allow a lot quicker load and save times, also multi threading the compiler which would drastically reduce the compile time for any scenario, etc. But the problem is, that the effort required for this task cannot be estimated from the outside, therefore we cannot really know whether it is a feasible effort or not. I thrust the LabVIEW team to make this decision and so far they decided it is not worth it.

 

As for why the compilation happens during close even when it is decided not to save the VIs: it saves all the information for linking in the current version of LabVIEW. If the compiled code is separated from the VI then it is saved in the compile cache (at least it allows the separate LV versions to have their own compiled codes). When choosing not to save the changes, then LabVIEW reverts all the changes that were only in memory and updated all the linking (type defs everywhere they have been used, subVI controls and indicators in their callers). I think the problem here is, that the development environment is not smart enough to filter out modifications that were only related to LabVIEWs internal libraries, i.e.: using VIs from the VI lib might trigger recompile because the above mentioned linking changes. When we click do not save then LabVIEW "reverts" these modifications and recompiles the code, not realizing that it actually will result in the very same compiled code, cause it won't call those VIs from the older LabVIEW.

Mads
Active Participant

Yes. If LabVIEW actually needs to keep a new copy and/or cached object due to a difference between the save version and the editor version, the copies should be kept separate from the original. And unless that code is actually edited, the copy should just be discarded silently, no recompile, no save. There is nothing to reflect into the original files anyway.

Yamaeda
Proven Zealot

Either it should be abortable, or it should ask about it before compiling when i choose to close it.
"Things have changed. Compile and save or close without compile?"

G# - Award winning reference based OOP for LV, for free! - Qestit VIPM GitHub

Qestit Systems
Certified-LabVIEW-Developer