PPLs are a powerful tool in LabVIEW, and when working on larger plug-in based applications, they're almost essential.
As a developer, I do my best to not reinvent the wheel. This means building modular libraries for common functionality. Sometimes this includes base classes and interfaces, sometimes this includes functional globals. If I'm calling either of these from a PPL, it's necessary to first put this common code in a PPL too -- otherwise there will be class conflicts or conflicting instances of functional globals.
I would love to be able to distribute this common code as a VIPM package to vi.lib so that it's reusable across multiple projects -- however that's simply not possible now. While yes, you can technically put a PPL in vi.lib, you're guaranteed to be met with failure as soon as you build an application that relies on PPLs calling the vi.lib PPLs.
There are workarounds to all of this of course, but they all come with compromises, typically maintainability -- such as including a copy of all of your PPLs (and in my case, a library of public VIMs that sits next to each PPL) with every project, while not having access to the common functionality outside of any of these projects.
The solution could be as "simple" as this:
- When PPLs are compiled, they currently expect each dependency to be at an exact relative path.
- Why not support loading from one of a number of paths similar to, say, how .NET finds DLLs?
- Search order could be something like: exact relative path, current folder, common LabVIEW folders, and custom (where custom could be defined in build specs)
- When building a PPL/application that relies on PPLs, if you don't exclude dependencies, this would now allow all of those dependencies to actually find each other.
