LabVIEW Project : Mass Compile automatically

[Mark_Ramsdale]

Is there a way to programmatically use the mass compile as it is used when in a LabVIEW project, that is, right clicking on the top of the project tree (The Project) and using mass compile ?

I have reviewed the articles on how to mass compile the directory, or mass compile all the VI's within the project ( requires some overhead).  

There doesn't seem to be a invoke node that, when you have a reference to the project, will allow you to mass compile the project.  No articles on point as far as I can tell.

A follow up question would be, is it better to mass compile the directory of a project, or each of the files within a project?  

[Darren · Accepted solution]

Will a 'Save All' operation on the project suffice for what you need? If so, there is a Hidden Gem for that:

vi.lib\Utility\EditLVProj\Save All This Project.vi

'Save All' and Mass Compile have some subtle differences, but if a 'Save All' will suffice for you, that VI should be all you need.

[Mark_Ramsdale]

Great suggestion!

A follow up.  We were discussing the difference between the following, and now I will include the "Save all" gem.

What is the "better way" for mass compiling code?   Would appreciate any weigh ins on this 

1) Load all VI's in memory, then compile them one at a time.  (note, if using 'tree' VI's this is facilitated)

2) Compile the directory ( recursively is automatic with the invoke node)

3) Compile each VI on disk one at a time  ( run through a list of VI's as opposed to opening them all at once)

4) "Save all" gem through using the the project API.

5) Mass compile in the project --->  as noted, there doesn't seem to be a programmatic way to do this.

Or are they all effectively the same.  That is, making sure there are no broken VI's and no cross linking, etc....

[Darren]

Mass compile will compile and save a VI if it detects that the VI is saved in an older version, or otherwise has something about it that requires a recompile (like being last saved on another platform). If the VI has been saved in the latest version on the same platform, and none of its linkages have changed (like subVIs having been removed or renamed), then mass compile won't actually resave the VI. Note that these rules are slightly different depending on whether you have the 'separate compiled code from source code' setting enabled on your VIs/libraries...if you do *not* have compiled code separated, then mass compile may save VIs that call subVIs or typedefs that changed, even if the calling VI didn't change.

If you want to force a compile of all the code in your project, then you'll need to write your own tool that opens a reference to every VI in your project and calls the Compile method of the VI class, with a "ForceCompile" parameter set to TRUE.

[Mark_Ramsdale]

Thanks again for the info.

I played around with my project hierarchy, and then ran "mass compile" (folder) and "compile" methods against the project folders and the individual files in the project.  Hopefully this will add to mass compile design decisions.

A few take aways, these might be obvious, but here they are:

1) Moving the VI's in "windows", then mass compiling the top level directory.  

• Calling VI's are compiled and saved.  
• Depending on the location of the moves, you might have to help LabVIEW find the files.
• In a deep hierarchy, moving VIs at different levels causes different VIs to compile.

2) For individual file compiles: Using the method of "self identification" from the project to get a list of VIs.  That is, the project tells you what VI's are in it.  Then moving VI's around in windows.

• If you automate the opening of the VI's, you can get errors as the project doesn't know you moved the files.  (Project gives you the path for opening, but the file has actually moved.)
• A suggestion is to mass compile the project folders first, then the individual files.  However, is this redundant to individual compile VIs after mass compiling the project folders?  (see below)

3) For individual file compiles:  Using a crawler to get all the file names.

• extra work to put a crawler on the front end.

Here is an open question:

Does mass compiling a directory hierarchy, with a project file in the top level, cause the same results as crawling through the same directory hierarchy and compiling each VI individually?

Spoiler

 I think it does, but no telling what might be under the hood of the mass compile invoke node.

[Petru_Tarabuta]

For quick reference, the invoke node that performs mass compiles programmatically is shown below.

Its online help page is found at: Mass Compile Method.

Other useful Mass Compile resources are:

• LabVIEW User Manual - Mass Compiling VIs
• LabVIEW Wiki - Application class/Mass Compile method
• NI Knowledge Base Article: How to Mass Compile in LabVIEW 

[rolfk]

---

@Mark_Ramsdale wrote:

Great suggestion!

A follow up.  We were discussing the difference between the following, and now I will include the "Save all" gem.

What is the "better way" for mass compiling code?   Would appreciate any weigh ins on this 

1) Load all VI's in memory, then compile them one at a time.  (note, if using 'tree' VI's this is facilitated)

2) Compile the directory ( recursively is automatic with the invoke node)

3) Compile each VI on disk one at a time  ( run through a list of VI's as opposed to opening them all at once)

4) "Save all" gem through using the the project API.

5) Mass compile in the project --->  as noted, there doesn't seem to be a programmatic way to do this.

Or are they all effectively the same.  That is, making sure there are no broken VI's and no cross linking, etc....

---

6) Not really applicable to projects itself but you can have a Tree VI that contains all the Top Level VIs of your project. For simple applications this would be usually not much more than a Splash Screen, the main UI and maybe one or three dynamically instantiated deamons. Then Ctrl-Shift-Click the run button on that VI. This goes even further than Masscompile as it will actually compile all the VIs currently loaded into memory, generally what your VI Tree references, and all their subVI even if they have no actual code change in any way. I sometimes used that in the past to detect rogue VIs that are not used anymore anywhere in the application by checking saving All and then checking the last safe date on disk. The project has this functionality now build in so haven't done this much, but it is a true Force Masscompile!