Strange VIM conversion and break down upon Source Distribution build

[X___]

I have a large project with many libraries which I am trying to release as a Source Distribution.

I am regularly releasing standalone executables of that project without a hitch.

However, the source distribution, once I open the top level VI in a copy of the project I place in the source distribution folder, after updating all paths to the new destination, ends up with many broken VIs.

Examining the source of the problem, it appears that it is due to many (if not all) VIMs in my project being replaced by VIs with made-up names (random series of characters.vi), and the Assert Type VIMs in those VIs being themselves replaced by similarly randomly named VIs, and broken.

I recall having read threads about some sort of incompatibility between VIMs and libraries, but since I did not have any problems with them during development (or application release), I am kind of at a loss as to what to do next...

Is there some literature I can read on the dos and don'ts of Source Distribution release and VIMs + libraries?

LabVIEW 2021 SP1 64 bits on Windows 10.

[X___]

I have answered my own question by not checking off the "Disconnect unused inline subVIs" checkbox.

However, I now have the issue that all the libraries in my Source Distribution now refer to the original paths of included VIs. This is strange as I have preserved the folder hierarchy when releasing the source, and I was under the impression that libraries, projects, etc. were relying on relative paths...

There seems to be no way for me to resolve these conflicts, and even if there was, I don't think this is a practical way to handle this type of release.

Does any one have any experience with this type of release (and actually tried to use the released source)?

Note that the exported project, even though it is riddled with conflicts does let me run the top level VI just fine, as if all this complaining about conflicts was just for show.

[X___]

This is too basic be of any interest to any of the gurus out there, so I am just typing this as a record of problems to be expected when releasing a source code in LabVIEW (in the way I had intended to do it).

Recap: I have a development folder where there are a number of VIs that I do not care to release (in addition to other files). That folder is under revision control by git. I do not want to make that repo public, but I want to release the actual useful code in a clean repo.

My approach: I select a Source Distribution in my project, in which I define which VI (+ libraries and other files) I want to save and where. There are a number of dependencies in other outside folders, which I export using the "preserve disk hierarchy" option to help with finding this VIs in the release.

When running the build, I have no issue. I need to create a different lvproj file in my release (but this is a one of affair) so that it doesn't refer to VIs that have not been released. I essentially drag all the lvlib files I have exported into that project, and reorganize things within virtual folders for convenience. If I open the top level VI in that project, and run it, everything works like a charm.

However, underneath the hood, everything is screwed up. Every single VI and library shows up as "in conflict".

Opening up the Resolve conflict dialog doesn't help, as none of these conflicts appears resolvable (all "Select this version" buttons are grayed out). The crux of the problem is that there are two available paths for each VI, the new and the old one. Clearly LV knows which VI to load when running the top level VI (the new paths ones), but somehow, the project is "in conflict" anyway. lvlib files seem to refer to VIs by relative path, so they shouldn't be the issue. VIs seem to store absolute paths in their data, so I suspect this the cause of the problem.

I have tried a number of workaround to fix the issue (releasing the distribution anew each time), to no avail:

- selecting different options in the "Additional Exclusions" tab

- uncheck "Preserve disk hierarchy" in the "Destination" tab

- Move the source to the same volume as LabVIEW (so that there is no need to distinguish between files in "C:" such as Windows dlls and files in the other volume)

[ShaunR]

I have similar problems now and again but it's not VIM's.

Some things to try to sniff out the problem:

Check project files and lvlibs with a text editor. If you have full file paths then that's a problem. File paths should be relative BUT! LabVIEW cannot always use a relative path (for example if it's on a network, different drives et.al.) Sometimes LabVIEW also gets confused but you need all paths to be relative even if it means reorganising how you structure your files.

Do the above and put all dependencies in VI.lib. If you are using source control, checkout dependencies to the VI.lib directory, not your own file organisational preferences (some people like to have them on a different drive, for example). The litmus test for this is that you should be able to move your project to different locations without getting the VI searching dialogue. The search will invariably put a full path in when it finds the file-don't let it. 

Recursion breaks the project conflict resolution. If you have recursive functions, make sure they are not broken by manual isepction. The usual symptom is that there are no errors in the error dialogue but conflicts exist and VI's are broken somewhere.

Polymorphic VI's hate recursion. If you are using polymorphic VI's recursively, don't use the polymorphic container (the thing that gives you the drop-down selector)! Only use polymorphic VI's as interfaces to other code - not itself. If you are using the polymorphic VI recursively then use the actual VI not the polymorphic container. If something gets broken you will go round in circles never getting to the broken code and multiple things will be broken.

Edited February 8, 2025 by ShaunR

[X___]

On 2/8/2025 at 1:06 AM, ShaunR said:

Check project files and lvlibs with a text editor. If you have full file paths then that's a problem. File paths should be relative BUT! LabVIEW cannot always use a relative path (for example if it's on a network, different drives et.al.) Sometimes LabVIEW also gets confused but you need all paths to be relative even if it means reorganising how you structure your files.

Tested that, all paths are relative.

On 2/8/2025 at 1:06 AM, ShaunR said:

Do the above and put all dependencies in VI.lib. If you are using source control, checkout dependencies to the VI.lib directory, not your own file organisational preferences (some people like to have them on a different drive, for example). The litmus test for this is that you should be able to move your project to different locations without getting the VI searching dialogue. The search will invariably put a full path in when it finds the file-don't let it.

As I mentioned, I moved my whole LabVIEW code to a different volume (by simply copying the whole development folder, preserving the folder hierarchy in which the different dependent libraries were located), and the project loads just fine. Since I am releasing the dependencies with the same folder hierarchy, I don't think this should cause problems to someone forking the repo. Having the dependencies in vi.lib would require messing up with the user's installation, which they may not want to do.

On 2/8/2025 at 1:06 AM, ShaunR said:

Recursion breaks the project conflict resolution. If you have recursive functions, make sure they are not broken by manual inspection. The usual symptom is that there are no errors in the error dialogue but conflicts exist and VI's are broken somewhere.

I don't think I have any of those.

On 2/8/2025 at 1:06 AM, ShaunR said:

Polymorphic VI's hate recursion. If you are using polymorphic VI's recursively, don't use the polymorphic container (the thing that gives you the drop-down selector)! Only use polymorphic VI's as interfaces to other code - not itself. If you are using the polymorphic VI recursively then use the actual VI not the polymorphic container. If something gets broken you will go round in circles never getting to the broken code and multiple things will be broken.

I use a few polymorphic VIs, but none recursively.

 

Overall it seems like I am better off writing my own source distribution release script, copying whichever file is needed, but that's sounds fairly tedious, as I would have to build a list of dependencies, etc. Or simply release a mock distribution to get that list of needed files, and then pick the original ones an copy them to my destination path?

[X___]

I tried the solution I sketched out at the end of last post and it appears to work like a charm, however moronic it may sound to have to do that to have a usable source distribution.

The post-build VI I am using is shown below for illustration.

The strange tidbit about llb's (bottom inside-most case structure) is something that I have added since the first version of that post as it turns out that LabVIEW doesn't deal properly with llbs when creating a source distribution.

When finding a VI inside a llb (say myLBLLB.llb in the original code), it will save that VI in a subfolder called myLBLLB.llb in the distributed source. That will then result in some compilation error that will prevent the release of the distributed source. The above post-build VI nukes this folder and replaces it by the actual llb (and therefore keeps VIs in that llb that may not necessarily be needed).

 

Edited February 13, 2025 by X___
fixed a LabVIEW bug in source distribution