Allow platform independent compile operations for all VIs

[gsussman]

This is something that would be a great addition for those of us working on different platforms (i.e. Windows and RT).

When a VI is compiled for a particular platform, add a seperate area to the actual VI file to keep the platform dependent compiled code. This way a vi that has been compiled for use on windows and for RT would have two sectons that keep a seperate copy of the actual machine code for each OS.

Where this issue becomes a problem is when you have common code called from a project that has both Windows and RT components. This creates an endless recompile operation as code is built

As an example:

Code is compiled for Windows.....windows machine code is generated and saved in the vi

Code is opened under RT.....changes pending because the compiled code does not match the platform

Recompile vi for RT....RT machine code is generated and saved in the vi.

When the code is reopened under Windows, it requires another recompile due to the existing RT machine code.

Obviously any changes to the FP or BD would cause all of the machine code areas to require a recompile. 

This would add more size to each individual VI, however disk space is relatively cheap with respect to LabVIEW development systems.

[Jim_Kring]

YES!!!

[PJM_Labview]

I also like this idea a lot.

[Intaris]

I made this suggestion a few years back so of course YES!

Of course it means that the compiled code for one platform (Mac) could be out of sync with the actual code within the VI meaning that running it on different platforms (without recompilation) could give totally different results.  A new form of platform-polymorphism?

Shane.

Message Edited by Intaris on 06-11-2009 02:11 AM

[mzaleski]

OMG!! YES!!!!

[Lavezza]

Intaris - The VI would have to keep track of which version the compiled code was for. If a VI is at version 12 and you open it up on Windows, it would check to see if the compiled Windows code was at version 12. If it wasn't, the code would get recompiled just like the current behavior. If it were done this way, you wouldn't have to worry about different results on different platforms. You would only get recompiles when the code was out of sync with the current platform.

[Intaris]

Lavezza,

yes but if it's not opened in the IDE but by an EXE then it CAN'T be re-compiled can it?

Shane.

[Lavezza]

Intaris,

True, but it still isn't as bad as today. If I open a VI today on a Mac and save it, even if I don't make changes, it can't be dynamically loaded by a Windows EXE. Using the method I suggested, it would be runnable as long as you hadn't made changes on the Mac. Either way, NI'd be able to make sure old code isn't run. Either the code it up to date, gets recompiled in the editor or fails in the executable.

Pat 

[Intaris]

Lavezza,

don't get me wrong, I'm all for it.  I have LV for mac and windows too, so I'd appreciate the change very much.

Shane.

[dwisti]

Great idea!

[rolfk]

Shane I somehow can't see the problems you see. Basically if you make any changes to the VI whatsoever in the editor except a clean recompile and decide to save that, LabVIEW would simply throw out ANY compiled code junk from the VI and only add the compiled code for the current platform. I don't think it would be feasable to distinguish between other code altering changes and non code altering changes to the VI to decide if compiled code junks need to be thrown away. Consequently upgrading a VI to a different LabVIEW version would also loose all compiled code junks.

I always thought that NI had crippled that capability needlessly, together with the capability to have multiple CIN resources for the same Code Interface Node in a VI, one for every possible platform. CIN's are more or less history but adding a capability for the VI would be great.