Best Practices for Distributing Code in Packed Libraries (PPLs)

[Will_S.]

Hi All,

We have recently been diving into using packed libraries to better control our reuse code. We have encountered one issue that I have not been able to track down a good solution for. The code in question uses a PPL plug-in architecture. We essentially follow the steps outlined here (https://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Librarie...) but take advantage of the more modern options for excluding dependent packed libraries.

Since we can make PPLs runnable by future versions of LabVIEW, we want our toolkit to be installed into any version of LabVIEW, and so had the plan to build all the PPLs into a common directory that mimics the directory structure that will be placed in user.lib. This way we could build the PPLs once and then use source distributions to place the PPLs in the appropriate LabVIEW directories, based on the target LabVIEW version.

This all works, except it appears the PPLs are using absolute paths for their dependencies. So when we deploy the source distribution and place a VI from the PPL that defines our API, we get a load warning that the dependencies were loaded from an unexpected path. After that, everything runs fine. But every time you load LabVIEW and use the toolkit, you get that warning. Not ideal.

So my question is: what are the best practices for distributing reuse code with PPLs and avoid these warnings? I understand we could create separate build specs for every version of LabVIEW and rebuild the PPLs, placing them in the correct locations. But that seems tedious. Is there a better way?

Thanks in advance for your thoughts.

[JÞB]

Generally speaking the user data folder is where it goes when you want support for multiple LabVIEW versions. 

[Will_S.]

---

@JÞB wrote:

Generally speaking the user data folder is where it goes when you want support for multiple LabVIEW versions. 

---

Can you elaborate? We certainly use User Data to manage things like configuration items. You put reuse PPLs in your User Data folders too, rather than user.lib? Do you use Public User Data to avoid path issues like this?

I should clarify: I said previously that we would be using source distributions to distribute. Really, we are building NI Packages to do the distribution. The source distributions are part of that process.

Thanks,

[mattbaker.digital]

Not sure if this will help, but if you build the PPL and explicitly include the dependencies as items in the project and build, it should keep all paths relative (providing they all have a common top-level directory).

For my PPLs built for use in user.lib, I move the PPLs in the Dependencies item in the project to a virtual folder called user.lib. LabVIEW seems to be poor at automatically including PPLs that reference other PPLs even though they are listed as a dependency, so this method gets around that (may be fixed in >2018). The only drawback is that the contents of the static user.lib virtual folder need to be manually updated if something changes (delete all items from user.lib and then move all items from the project dependencies back into there).

Example structure:

PPL build spec config:

PPL dependencies -> Always included

 

The contents of the destination/build directory should then be compatible with the intended user.lib layout and the built PPL will have relative links to its dependencies (../<lib name>/<lib name>.lvlibp) instead of absolute paths to C:\<path to LabVIEW user.lib>\

 

 

[Will_S.]

Just in case this is helpful for someone else, it turns out that the load warning was actually caused by a Friend PPL. It appears that the Friends use static paths, and so when we moved them to a new location with the source distribution, they would show the load warning. 

In order to get around that issue we built the Friend PPLs once and put them in the desired end locations (i.e. user.lib). Then we added those PPLs as Friends instead. This allowed us to build all of our PPLs and deploy to user.lib without having our users experience a load warning every time they use the toolkit.

[pawhan11]

Also very interested in this topic.

Approach that I use now is:

- all PPLs go into one directory to keep relative paths between PPLs simple if they depend on each other. I had one project where in order to use one PPL I had to mimic strange folder structure...

- each project has dedicated 'bin' folder where all PPLs go. If I would put this into userlib I would be forced to use specific version of given ppl and this might change based on projects.

- custom made powershell script that gets project dependencies (valid ppl versions) from network drive where they all go once released. We are currently moving code to hithub so i imagine script will get released ppls from github.

I really wish NI could put some effort into per project package management...

[richjoh]

"Diving into using packed libraries to better control reuse code". I'd prefer to use a revision control software than a compressed compiled Labview. As you know, beginning with Labview 2017 and on, the version doesn't need to match the PPL version. Less of a headache. Your taking the time to create, build, link and rebuild PPL eating away time. You want to implement strict code reuse, IMHO using PPL for that creates more problems to deal with from reading this thread and the linked thread. PPL appears to be only good for distribution to the customer (your Labview code Block Diagram does not exist). I have found no other good use for PPL.

[Will_S.]

---

@richjoh wrote:
"Diving into using packed libraries to better control reuse code". I'd prefer to use a revision control software than a compressed compiled Labview. As you know, beginning with Labview 2017 and on, the version doesn't need to match the PPL version. Less of a headache. Your taking the time to create, build, link and rebuild PPL eating away time. You want to implement strict code reuse, IMHO using PPL for that creates more problems to deal with from reading this thread and the linked thread. PPL appears to be only good for distribution to the customer (your Labview code Block Diagram does not exist). I have found no other good use for PPL.

---

Yup, that's exactly it. We plan on using this code both internally and externally. I see the following benefits:

• This makes distribution and support much easier as we can simply ask a client what version they are using by looking at NIPM.
• Fixes are easier as well by either drop-in replacements of PPLs or providing a new package for them to install.
• Building EXEs and other PPLs with the code and plug-ins is much easier for less experienced programmers since they just have to include the directory of PPLs in their project and then create a destination for that directory. 
• Block diagrams are protected if necessary.
• A user can't accidentally make a change to functions that changes the behavior on their PC compared to others.

But to your point, developing while relying on PPLs is much more complicated.

[richjoh]

• This makes distribution and support much easier as we can simply ask a client what version they are using by looking at NIPM.
• Fixes are easier as well by either drop-in replacements of PPLs or providing a new package for them to install.
• Building EXEs and other PPLs with the code and plug-ins is much easier for less experienced programmers since they just have to include the directory of PPLs in their project and then create a destination for that directory. 
• Block diagrams are protected if necessary.
• A user can't accidentally make a change to functions that changes the behavior on their PC compared to others.

---

Good points but no different than link, compile, build distro, revision/commit/push source code. I respect your choice, since it's your way of doing this task you see benefits.