LabVIEW
Can't create a Source Distribution to a single LLB
That is expected if you use classes. A LLB is an old technology that predates LabVIEW classes for many many moons and was not designed with this in mind. It has no directory structure internally so all VIs must have different names to avoid conflicts. So if you have multiple classes that derive from each other you ineviatably end up having VI overrides which by the very nature of an override must have the same name as the overwritten method and can't exist in the same directory as its parent method. With an LLB only having one directory level this is not possible!
So the Source Distribution Builder moves these VIs into separate directories next to the LLB! Use ZIP files instead for source distributions, they allow for an internal directory hierarchy and can handle LabVIEW class methods in the same way as is done on your file system.
LLBs are 30+ years old! They only have one directory level, a minimal compression scheme, no real safety at all to protect against even single bit errors in the file stream, resulting frequently in corrupted LLBs whose contents are simply lost, and they are very bad if you want to do software version control since they are one huge BLOB that needs to be (for GIT) completely backed up to the revision control server at each even minimal modification to any VI inside it.
Basically if you want to transport your sources in a single file, use ZIP. Use of LLBs only will seduce the recipient to try to use the LLB as is in his application and create all above mentioned problems and then some more. That all said, inclusion of VIs in vi.lib such as the Report Generation Toolkit in your source distribution is not recommended. They should be referenced from the original location as they refer to dynamic VIs that your Source Distribution Builder doesn't know about and won't include and they are a licensed feature that you can't just copy around and give away to other people at will.
@Discrusio wrote:
The Source Distribution LLB shall be used in TestStand.
Maybe I shall look closer to the Packet Project Libraries, instead of the old LLB?
That's most likely the better solution anyhow. It would likely allow to execute your TestStand steps with just the LabVIEW runtime installed.
