Determine if Caller is Compiled inside LVLIBP

[Shane-C]

I have read several posts about how the Conditional Disable Structure is compiled already and thus I can't use it to check in an LVLIBP if it's compiled or not.  What I want to do, however, is check inside the LVLIBP whether or not the calling code is compiled or not.

How can I write a SubVI inside a LVLIBP that will tell me if the calling VI is inside an EXE VS in development environment?  I have tried several options so far including "AppKind" for a calling VI and compiler flags but those don't work because the flags are evaluated already.

[UliB]

What about using 'Current VI's Path' and looking for '.exe' in it?

I don't know what the path will look like in a LVLIBP.

[rolfk · Accepted solution]

Generally the most promising way is to use a method where you use the Current VI Path of a VI inside the library to consecutively strip one path element until the Get File/Directory node returns no error. This is either the VI (source code), the lvlibp (inside packed library) or the exe (inside a built executable).

If you want to make this work also for other platforms than Windows, you may have to be a little more diligent about just relying on the file extension. On Linux and Mac an executable does not need to have a specific extension for the OS to know that the file can be executed. Instead you would also need to check the File Permissions for the x flag. But that doesn't exist on Windows.

Unless you use the LV 8.x file layout checkbox in the Build Settings for an executable, the path of a VI is the path of the exe or lvlibp plus the relative path of the VI in respect to the project/build location. So it can get quite deep for complex project hierarchies, but that is not a problem in itself as LabVIEW never tries to access those VIs through normal file IO routines and it can itself handle very long paths with 255 directory levels with up to 255 characters each. But it can go wrong during building of the exe or lvlibp as LabVIEW generates the resulting layout on the Build location on disk before packing it into the binary file container and here the path length limit of Windows matters. Generally the Destination Path in the Build settings should therefore be as short as possible for problematic project structures with deep nested file hierarchies of all its libraries and VIs.

[Shane-C]

Thanks so much for the advice here, this pointed me in the right direction!  I needed to check "VI Path" not on the Current VI, but rather on the calling VI.  That said, this does the trick.  If I use "Current VI Path" inside the subVI then I get the same path to the inside of the LVIBP either way.

I am doing this on RT Linux, so I was curious about your X flag method and was messing with that too.  I'm confused though on how that's meant to work.  What specifically are you targeting when looking at the X-flag?  The RTEXE?  I tried looking at permissions on my RTEXE and got 436, none of them are marked as executable permissions.  It also wouldn't be different when I run as source because the RTEXE is still on disk even when I run from source while debugging.

[rolfk]

Ahh, well! That was a bit of a short circuit. The rtexe may look like an exe because of the similar name, but is in fact really more like an archive containing the LabVIEW binary resources that then need to be invoked through the LabVIEW runtime system on the realtime target. I was thinking you were going to use normal Linux.

Your value 436 means 0664 which indeed just means rw-rw-r-- so no execute attribute at all.