EXE Won't Build

[Hooovahh]

But this time its different because I can reproduce it and demonstrate it.

So I have a large project with several libraries and classes.  I've been updating code and in doing so added a new library.  After adding the new library my application no longer can be built.  It returns an error stating "Cannot save a bad VI without its block diagram."  I open the VI and of course it isn't broken.  I performed a mass compile but still no build.  So I start a binary search disabling parts of the code until it starts working again.

I was able to isolate it down to a single spot where I have a false constant, wired to a case structure that either calls a VI in the TRUE case, or does nothing in the FALSE case.  If I disable this code it builds fine.  If I turn the constant into a control it also works fine.  This makes me believe there is a problem with constant folding and removing a part of the code that it think it needs.

I played around a little more and with my minimized project I could get it to work by doing things like Disconnecting Type Defs in the application builder settings, but this didn't fix it in my larger application.

But one thing I noticed that did fix my build in both the full application, and the smaller test one is adding the LabVIEW band-aid "Always Copy" between the boolean constant, and the case structure.

So NI can you look into why this build fails, and try to fix it assuming I haven't done anything wrong.  This issue has been seen in LabVIEW 2012 SP1, and 2013 SP1 in Windows 7 x64.

[mikeporter]

I have also noticed that LV sometimes has trouble with the concept: "disabled".

I have seen broken code in a disabled frame of a Diagram Disable Structure keep a build from completing.

Mike...

PS: And don't get me started on the screwy things that can keep an installer build from working...

[RavensFan]

I tried building your application as is, and it built just fine for me.

---

@Hooovahh wrote:

I was able to isolate it down to a single spot where I have a false constant, wired to a case structure that either calls a VI in the TRUE case, or does nothing in the FALSE case.  If I disable this code it builds fine.  If I turn the constant into a control it also works fine.  This makes me believe there is a problem with constant folding and removing a part of the code that it think it needs.

---

I think you have this sentence stated wrong.  LabVIEW actually removes code that is knows it doesn't need.  That behavior changed around LV 8.2 ??  And is why upgrading old VI's with constants wired to case structures will convert them to hidden controls.  In old LV, code inside cases that could not be called would still be included in the build.  With newer LV versions, code in those inaccessible cases is stripped out and not included in the .exe.  Since this might change the behavior of an older application where someone may have want to force code to be included, but not run by burying it in a case structure that can't run, NI upgrades that code to put it in a case structure selected by a control.  Since it doesn't know until runtime whether that control will be true or false, it is forced to include the code in the .exe.

Now I don't know why your library is behaving like it is broken.  I wonder if you put the library in the "Always Included" section of the build spec if it will build for you.  That should cause the same results as having the VI in a case structure controlled by a control, that is LV will be forced to include the library within the build.

But I'm sure the cause is that the you are using a control that has its typedef defined in the library.  If that library is not being included, then the build is not going to work because it can't find the typedef.  But I don't know why the compiler doesn't realize it is grabbing the typedef from the library and trying to include that within the build automatically.

[Hooovahh]

---

@RavensFan wrote:

Now I don't know why your library is behaving like it is broken.  I wonder if you put the library in the "Always Included" section of the build spec if it will build for you.  That should cause the same results as having the VI in a case structure controlled by a control, that is LV will be forced to include the library within the build.

But I'm sure the cause is that the you are using a control that has its typedef defined in the library.  If that library is not being included, then the build is not going to work because it can't find the typedef.  But I don't know why the compiler doesn't realize it is grabbing the typedef from the library and trying to include that within the build automatically.

---

Adding the library to Always Include still fails the build.  Attached is the detailed log from the build attempts.  I've tested this on two separate machines that have similar setups but that should eliminate a suspected corrupted LabVIEW install.

I think you misunderstood what I was saying.  I know how constant folding works (high level) and that I figured that is why when replacing the constant with a control it worked, and adding the always copy worked.  My statement was saying that I believe LabVIEW is removing code it thinks it doesn't need but it actually does.  I thinks it doesn't need it because there is a constant and the state never goes in there.  But for some reason when I convince it to include it with a control it is fine making me believe it is doing something wrong.