Application Build Preview should handle conditional disable structure updates if needed

[Mads]

If you have a project where a VI is used on multiple targets, and contains conditional disable structures that vary between the targets (loading Vis that are not compatible with all targets for example) - you may see application build previews fail until you open the affected VIs on the relevant target just to get LabVIEW to update the conditional disable structure.

The actual build is smart enough to do this, but the preview function is not. This has the funny side effect that installer builds can fail when the relevant application builds suceed; because the installer will run a preview on the application builds even though they are already successfully built, and then fail because the preview will fail.

Now, I'm sure the installer build's use of the preview has its good reasons so I will not suggest to remove that, but rather suggest that the issue is resolved by making the preview functionality smarter; If (and only if) it runs into trouble when generating the preview, it should do the same as what the actual application build is now able to do; load the troublesome VI - and see if the issue is easy to resolve on the fly.

[AristosQueue (NI)]

Hm... you raise an interesting conundrum.

The single most expensive single step of AppBuilder is loading and recompiling your source VIs. Preview is meant to avoid that. If we have to load and compile in order to generate the preview, we might as well remove the preview. Currently, we just read the dependency list that was saved with the VI or its cached compile image (depending upon whether you have Source Only enabled or not).

I'm not sure how we would reconcile these requirements. Still, the idea is worth leaving open.

[Intaris]

I suppose it could be clever enough to detect if a conditional disable has beenaltered?  Only when this is the case would it be required to load and recompile a VI.  I would imagine this would still save considerable time over a full build.

[Mads]

AristosQueue wrote: 

"The single most expensive single step of AppBuilder is loading and recompiling your source VIs. Preview is meant to avoid that. If we have to load and compile in order to generate the preview, we might as well remove the preview."

Sure, if the preview was just used by the user to get a quick preview, it would not make sense to make it automatically do stuff that might cause it to take so much time...(again, with the suggested implementation this would only happen if it failed though, so instead of just returning with an error it could ask the user if it should continue generating the preview or not when it finds that it has to load VIs). However - the preview functionality is obviously also used when a installer is built; and for such use the time issue becomes less important. There it is not fit for purpose (nor currently properly conveyed to the user upon failure) that the installer build might fail due to a weakness in the preview functionality.  

[AristosQueue (NI)]

That would mean

a) making the info about "which conditions were true the last time the VI compiled" accessible without loading

b) making the info about "all conditional disable structures and their conditions" accessible without loading

Not impossible by any stretch, but substantial reworking of saved information.

[Mads]

That is based on your knowledge about the inner workings of the preview function I guess:

I imagined that the preview function was still treating VIs in a way that would allow it to single out which VIs were causing the preview to fail; and then it could choose to load those VIs only (with dependencies obviously). If it currently concludes that it fails without really having any information about the source of the problem, then I understand that the change would be a bit more elaborate.

Again - the fact that the installer build is calling the preview is what (should) adds to the requirements list for the preview function. 

[AristosQueue (NI)]

Loading any single VI loads its entire hierarchy. I'm not sure if that's acceptable -- every time a preview build would fail, we load all the broken VIs to see if they just need a recompile? That would almost kill the utility of the preview, I think.

[Mads]

Might not be acceptable for a human user that just wants a preview (he could get the option to OK it if needed though (the preview should, like many others htings, perhaps show a progress bar with a cancle option, but that probably raises other issues). 

Add a mode input to the underlying preview function; prioritize speed and skip any further checks / just return error when called by a user,  or prioritize robustness when used by the installer build (I do not know if LabVIEW calls this other places too, if it does the prioritization might be relevant there too...).

[AristosQueue (NI)]

I can see that as feasible, Mads.

[Bob_Preis]

Hi Mads,

I'd be interested in taking a look at a simple reproducing scenario if you have one. On first preview (ie before caching), this shouldn't happen, but there may be a case where the preview cache detects no changes in source checksums, conditional symbols, etc, and returns all cached dependencies instead of recalculating.

[Mads]

I'll see if I can strip down the project to work as a demo. I can provide a compressed description in writing for now though:

One project, containing:

4 targets (PC, cFP-2220, sbRIO-9651, cRIO-9030), all with an application build with the same main.vi as top-level.

The PC target has a plugin (will be dynamically called only) included in the build spec which is placed into an .llb. In this plugin  there is a conditonal disable structure that removes LED-controlling VIs from its code if the target is a PC.

(All VIs are set to separate compiled code from source code by the way.).

Now perhaps due to work on one of the real-time targets, the plugin VI will, if we open it on the PC target, always start to look for the LED VIs even though they are not to be used on that target...We can cancel that search and the conditional structure will make sure it does not break the code after all...or let it run. In any case if we have not done this prior to running a Preview on the application build - the preview will fail. *Buidling* the application on the other hand will *not* fail, so if we  just start building the application, then the installer - the installer will fail (due to its use of preview).