Exclude code in diagram disable structure from application builder

[Worle]

Is there a way of forcing the application builder to ignore code in diagram disable structures.

I tend to put unit tests (I am using Caraya) in a diagram disable structure inside of the VI being tested. This is causing the Caraya library to be compiled by the application builder.

C:\Program Files (x86)\National Instruments\LabVIEW 2023\vi.lib\addons\_JKI Toolkits\_Caraya_internal_deps     contains files with very long file names which is causing the application builder to fail

I am aware that I can fix this by selecting 'Use LabVIEW 8.x file layout' in the build spec which normally fixes the problem, I am still interested to know if there is a way of removing the problem entirely without removing all of my diagram disable structures.

Part of why I am interested is I have also run into issues if I have a broken VI inside of a diagram disable structure. This causes appears to cause the application builder to fail with an unhelpful error message.

[tst]

I thought LV doesn't include VIs in disable structures, but I guess it does if you do see them.

A couple of potential options, off the top of my head:

1. Set the build target to be a short path (e.c. c:\1), so at least that part of the path is short.
2. Create a pre-build VI which will iterate over all of the relevant VIs and remove the disable structures. This will probably require getting the top-level VIs (either from the build settings, which can be a bit trickier or from you) and iterating over all of their callees. I don't remember offhand whether the actions performed by the pre-build VI are performed on the original VIs or on a temporary copy held in memory in a separate instance. If it's the original VIs, you will also need to revert the changes at the end of the build.

[Worle]

I thought LV doesn't include VIs in disable structures, but I guess it does if you do see them.

I used to think the same, but recently I have realised it is very much not the case. I have yet to work out exactly what the logic it behind causing it to be compiled.

Set the build target to be a short path (e.c. c:\1), so at least that part of the path is short.

This also sometimes works, with RT builds (Possibly with other as well) the code appears to get saved to a temporary directory first and that can also end up being too long. I have had to enable the build spec log to work that out as from memory it is not visible in the build spec error message which gets displayed. (Enabling the LabVIEW 8.x file naming does also fix this specific problem)

Create a pre-build VI which will iterate over all of the relevant VIs and remove the disable structures. This will probably require getting the top-level VIs (either from the build settings, which can be a bit trickier or from you) and iterating over all of their callees. I don't remember offhand whether the actions performed by the pre-build VI are performed on the original VIs or on a temporary copy held in memory in a separate instance. If it's the original VIs, you will also need to revert the changes at the end of the build.

I have considered this, I was just hoping there was a neater solution/ someone could give a bit more context on what is going on under the hood

[JÞB]

I would like to see a snippet of one of the disable structures that you suspect.   

Generally,  UT code would be in a conditional disable structure to facilitate programmaticly switching to test mode.  If that switch is a constant the unreachable code will be removed by the compiler optimization. (CAVEATE: The LabVIEW.ini contains a optimization setting Int 1-10 that may change that.)  If a control or Global Variable is used as a switch, the code will NOT be unreachable and cannot be removed. I suspect that this is what you are experiencing. 

Another option comes to mind.  Frankly, I haven't tried but, it "Should work" ( see signature line)  place your test code conditional disable structures and switches inside Symbolic Disable Structures that use null code when the environment is not the development environment.   This should make the whole UT code unreachable in the executable so the application builder will exclude the CDS and the "Test mode" switch. 

[paul_a_cardinale]

If an output from disabled code is wired to a tunnel (even if no other cases are wired to that tunnel), and the data type is typedef'd. then that type definition will necessarily be a dependency in all cases.

Likewise if a static VI ref is wired to a tunnel.