LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
Top Authors
cancel
Showing results for 
Search instead for 
Did you mean: 

Force Recompile option in Mass Compile

LabVIEW is awesome. But sometimes things don't go quite right, and when something isn't quite right somewhere (maybe a bad bit of binary) it would be great to be able to recompile your code. Mass Compile is great for upcompiling from older major versions, but will ignore VIs that are already compiled in the current version. What I'd like to see is a "Force Recompile" flag in Mass Compile to ensure all identified VIs are most definitely recompiled, especially useful when you call Mass Compile from the shortcut menu in Project view.

 

Yes, it could take some time, but less time than scripting it and you can use the time to make yourself a nice cup of hot British tea.

 

forcerecompile.png

Thoric (CLA, CLED, CTD and LabVIEW Champion)


25 Comments
Active Participant

The fact that none of us knew about the current behaviour is interesting. Adding the option would instantly plug that gap in the general understanding...

--
Chris Virgona
Active Participant

The reason mass compile does not force a recompilation of everything is that it basically has to start all over each time it has compiled an item. That has to do with dependency tracking. You can extrapolate yourself to get an idea of how many days some mass compiles could take.

 

There is already a way to make mass compile recompile everything. I think it's an ini token, but I can't remember which one and I'm in a hurry right now so haven't got the time to find it. I'm in favor of bringing this functionality forward into the public domain with a checkbox, but for performance reasons I'd oppose making the forced recompile of everything the default behavior.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Proven Zealot

I didn't know that Mass COmpile didn't already force recompilation.  I learned something.  That's your fault Thoric!  Smiley Happy

Active Participant

@Steen: I can appreciate that a forced mass compile will take some time, but tackled intelligently one would work from the bottom up to ensure re-recompiles are minimised. I searched but couldn't find anything about this special ini token.

 

@Intaris: Happy to make your day Smiley Wink

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Active Participant

Hello everyone,

 

For a bit of background I am going to borrow from a post my colleague made - 

A given VI stores 2 different version numbers; the Editor version and the VI version. The Editor version changes with every Patch (f1, f2, etc) and Service Pack, but the VI version only changes with major version releases (2011, 2012, 2013, etc). 

 

The VI version is used to determine whether the VI needs to be upconverted or downconverted (i.e. changed LabVIEW features mutated and code recompiled) in order to open. When the Editor version differs, none of those things happen; the code isn't recompiled, and VI will not need to be resaved. However, Mass Compile does look at the Editor version when determining whether to recompile code (e.g. Mass Compiling 2013 f1 VIs in 2013 f1 won't recompile anything, but Mass Compiling 2013 f1 VIs in 2013 f2 will recompile everything).

 

As the document Thoric linked to states - mass compile loads each file into memory and saves it, it will do a recompile if either the editor version or the VI version are different than the development environment version, but will not do a recompile if the versions match. Even though there may not be a compile, mass compile can still fix cross linking issues.

 

There are a few ways to force a compile:

 

CTRL + Run Arrow: This will force compile the VI you are running this on.

Clear the objcache: If your VIs are using Separate compiled code from source file then you can clear the VI objcache through Tools>>Advanced>>Clear Compiled Object Cache which will delete the compiled code and require a recompile.

CTRL + Shift + Run Arrow: This one is a bit more complicated. It will force a recompile of everything that is in memory and in the same context as the VI you are click the run arrow on. So if you are using OOP, this can recompile your entire class hierarchy. If you use this on your top level VI, it will recompile your hierarchy (although it will not touch any dynamic dependencies).

 

I agree that mass compile not actually doing a recompile if the version is not bumped is not intuitive. However, what is the use case where you would want to force a recompile of a directory structure and the above shortcuts would not work? A witchhunt for bad binary somewhere in the code base?

 

When we release patches/service packs, we will occassionally include fixes that require a recompile for the fix to take effect. We make a note in the readme that a recompile is required for the specific fixes and where possible, we often include VI analyzer tests to help find the affected VIs. This is a big use case for mass compile, because the patch/service pack will bump the Editor version and a mass compile will recompile all the VIs that it touches to the new editor version.

 

As a side note, the reason we don't bump the VI version with each patch/service pack is that would break run-time compatibility within a given version of LabVIEW. IE 2012 SP1 exes could not run on the 2012 runtime engine - but since we only bump the editor version SP1 and non-SP1 RTEs can be used interchangeably.

 

I hope that clarifies this a bit.

 

Thanks,

 

Jeff Peacock

 

Product Support Engineer | LabVIEW R&D | National Instruments  

Member

Thanks to all involved for the information. This behavior may explains a lot insomuch as often mass-recompiles fail to address issues I'd expect recompiles to address.

 

I too am surprised how many people didn't know this behavior, myself being among them.

 

-mje

Active Participant

Thanks Jeff.

 

My use case is usually precisely as you describe - a witch hunt. Often when I find something untoward is occurring, a recompile of the entire tree can solve it. I often call Mass Compile from the project view (right click Project: xxx.lvproj > Mass Compile) which recompiles everything in the project - or so I thought anyway.

My alternative is a CTRL+Shift+Run on the top level VI, and manually loading all dynamically called VIs and performing the same action there. I use dynamic calling a lot, so this is painful and error prone.

 

For me, a simple "Force recompile" switch on Mass Compile when applied to my Project tree would save me a lot of effort. Maybe it could also use "skip vi.lib/instr.lib files" option to ensure we don't end up recompiling too much, just our own code.

Thoric (CLA, CLED, CTD and LabVIEW Champion)


Active Participant

Thoric, I often build an "All.vi" that just has all top-level items on its BD (including all dynamic VIs), such that I have one central component that I can load when I need to make a global change that affects the entire application. Such a situation could be global mass compile, or it could be when I need to make several changes to an enum and need each incremental change to update all callers before applying the next change etc.

 

Such an "All.vi" is also a good point of reference to see if there are any broken VIs in the entire project, instead of getting error 1003 (or one of its cousins) at runtime when you attempt to call a broken dynamic VI you hadn't spotted (the goal is that the "All.vi" may never have a broken arrow). I just wire some dummy data to any required inputs on each top-level VI. I'd then include this "All.vi" in the project under each target, and have target-specific disable structures inside the "All.vi" so it can also contain Real-Time and FPGA VIs without sporting a broken arrow.

 

But this is still not quite the same scenario as when you want to enforce mass compilation on a folder for instance, where your idea is the quicker solution.

 

/Steen

CLA, CTA, CLED & LabVIEW Champion
Active Participant

In addition to Jeff's recommendations for forcing a recompile, there actually is a flag you can set that will cause a recompile of every VI loaded through the mass compile function. In older versions of LabVIEW, there were some bug fixes in maintenance releases which required a recompile in order to get the fix. For instance, in LabVIEW 8.6.1, Corrective Action Request 128115: Incorrect behavior in case structure execution required a manual recompile of VIs (see the readme). In order to force compile all VIs loaded in the hierarchy using the Mass Compile dialog, you can set the LabVIEW ini key massCompAll=True. This effectively does what is requested in this idea, it's just not exposed through the dialog (I'm not sure why).

 

This method may work for you until it is actually exposed in the dialog. I have used it on several occasions. It is a bit more work to close LabVIEW, change the INI file, wait for everything to be recompiled and then undo the INI changes, but it works.

Donovan
Active Participant

@Donovan: Thank you for that information, that's great to know!

Thoric (CLA, CLED, CTD and LabVIEW Champion)