Source Distribution vs Packed Project Library

[LJHerskowitz]

I am designing my architecture for a project, and I want to use plugins for future expansion. Most of the information I found recommends using packed project library for each plugin. But every once in a while I find someone who recommends using source distribution. I plan on creating this software to end users who do not have development environment and who should not be allowed to modify the code. 

So I have a couple of questions.

1. What is the difference between source distribution and packed project libraries?
2. What are the advantages of one over the other for plugins?

[tyk007 · Accepted solution]

Source distribution contains the source. It lets the end-user upgrade the source to their version of LabVIEW (development envinroment only) since the source is version dependent, and if the files are saved with complied code they can work in a run-time envinroment at the version of LabVIEW they were last compiled in. Distributions of this nature though tend to have several files to deploy. One of the main reasons to prefer this method is due to the complications of "chaining" packaed project library dependencies which we are stuck with until NI comes up with a "solution" type for controlling this.

Packed project libraries are built (run-time compatible) which do not require the development environment and are typically single file making them easier to deploy. However they are built to a specific version of LabVIEW. One of the main reasons to choose this method is versioning (the files have version information) as well as ease of deployment (single file).

At the end of the day it depends a lot on your end-user in my opinion. Managing multiple files is a pain from a source distribution stand-point but then so is chaining builds for packed project libraries and the inevitable name-spacing issues that comes with it. Managing dependencies is never easy and there is no easy silver bullet for this in LabVIEW.

[LabVIEW-Surfer]

I agree with the points above, however, as Elijah Kerry mentioned in his post: https://ekerry.wordpress.com/2013/12/07/the-nuances-of-deploying-plugins-in-labview/ there are solutions to the challenges of Source Distributions, as well as using

• Libraries for the namespace,
• the build log file for the version information,
• Remove front panel and block diagram for avoiding code modifications,
• Using MD5 hashes to verify data / code integrity
• Use packages and SystemLink for deployment automation,
• Etc.

Still, all Architects I know use PPLs (*.lvlibp). Or is there anyone out there that uses source distributions for deploying plugins?

What are your reasons for preferring one to the other?

Are there reasons why you strongly recommend avoiding one to the other for deploying plugins?

[crossrulz]

I am a fan of PPLs.  I much prefer placing a single file into a specific location to add a plungin than copying an entire source distribution, which has many possibilities of causing other conflicts.  The PPL has a copy of its dependencies other than other PPLs inside it.  You just have to watch your relative paths when building and distributing.

[avogadro5]

I prefer source distributions for plugins (assuming plugin developers are allowed to access the source of the API). The biggest reason is the existence of the "Always Excluded" setting in source distributions, which lets me exclude everything in the caller EXE (which I do via a script). This results in a very fast build and load of the plugin by eliminating redundant code from the build.

Additionally I dislike several aspects of the rigid namespacing of lvlibps:

1. It forces me to use LVLIBs even when not otherwise needed
2. It (de facto) forces plugin developers to develop using locked dependencies, so they can't readily insert "cheats" like extra logging to help them debug
3. It results in duplicated dependency code (like everything from vi.lib)
4. I can exclude files from the PPL for namespacing or file size reasons by placing them in the support directory, but the files still have to be created/compiled even if I don't want them which wastes compile time

These are all outweighed if there's a serious need for the extra protection/privacy, such as IP protection.

Would be glad to hear workarounds to make packed libraries seem better!