Home Community Discussion Forums Most Active Software Boards LabVIEW Topic

LabVIEW

cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

Packed Project Library (PPL) Plugin Architecture - Development vs Distribution Dependency Architecture

Packed Project Library (PPL) Plugin Architecture - Development vs Distribution Dependency Architecture

‎08-21-2024 10:52 AM

We have been putting together a plugin architecture using PPL's over the past couple of months, although there are many caveats we have encountered and worked around, there still seems plenty out there that we are learning about.

Currently all of the PPL's we are using exist in a flat structure and we would like to improve this - making sure developers and operators don't delete core functionality and having applications able to access the same PPL's.

We have started to look at a PoC and had some thoughts/issues that we need to look at..
 
Proof of Concept Background:
At present we have:
  1. Core PPL's (ProgramData) - hierarchy of various packed libraries that are used at the core of the functionality, not hugely relevant what these do but it is worth knowing that there is class inheritance for abstraction of functionality that subsequent PPL's can then implement (it is a plugin architecture after all).
  2. Developed PPL's (Public Documents) - utilizes the "Core PPL's" within it's functionality, again not important what it does but there may be a couple of layers of inheritance from "ProgramData" and then from "Public Documents".
  3. Application - an application that directly uses the "Core PPL's" and the classes contained within them, this will then use the factory pattern to load in "Developed PPL's". This should then be distributed and know where the "Core PPL's" are located and use them without having to include them in the "AppData" folder upon build.

Inheritance:

Inheritance is a core part of the plugin architecture, this spans across multiple locations rather than one folder with a flat structure.

  1. X - ..\ProgramData\dependencies\core\core.lvlibp - parent class contained within (core.lvclass)
  2. Y - ..\ProgramData\dependencies\core\child\core_child.lvlibp - contains class (core_child.lvclass) that inherits from "core.lvclass"
  3. Z - ..\Public\Documents\plugins\driver.lvlibp - contains class (driver.lvclass) that inherits from "core_child.lvclass"
  4. W - ..\Public\Documents\plugins\instrument\instrument.lvlibp - contains class (instrument.lvclass) that inherits from "driver.lvclass"

 

Considerations:

  • Bitness - we need to have each of the PPL's built in both bitness, this means that we would like to find a way to do the building in each version of LabVIEW from the same project into the correct location (Post-Build Action solves this) and also manage dependencies in each version of LabVIEW from "ProgramData" or "Public Documents" (not vi.lib..)
  • Avoid Duplication - Currently in order to perform development we require duplication, maintenance and distribution of 2 sets of PPL's, one for development (in vi.lib) and deployment (Public Documents). The duplication is to ensure that the entire hierarchy exists in both locations without conflict (LabVIEW loves to crash if you get this wrong). The main issue with this, apart from being human and forgetting to move things around, is developer experience, currently if a developer creates a plugin Y that inherits from X plugin in "vi.lib", and wants to then create Z that inherits from Y, the developer will need to manually move Y to vi.lib after building before doing so first.
  • LabVIEW Agnostic Distribution - this all needs to work on a machine that does not have LabVIEW installed. "vi.lib" may not exist

 

Problems:

Currently the issues that we are having are as follows:

  1. Project File Paths - we are attempting to open a project with a dependency to a PPL (e.g ProgramData), if these PPL's do not exist in a LabVIEW VI symbolic path (e.g vi.lib) then it maintains a relative path to the PPL dependency rather than absolute. This causes an issue on different developer machines as they likely keep their source code repositories in different locations.
  2. Bitness Dependencies - previously we have been installing the "Core PPL's" into vi.lib (using VIPM), this means that irrespective or LabVIEW bitness the correct dependency is always present based on the relative path. If however we move the "Core PPL's" to one centralised location in "ProgramData", we cannot auto-resolve the dependency as the project (.lvproj) file has reference to that unique path. Feels like we want to be able to create our own symbolic path outside of the LabVIEW core files..
  3. Application Dependencies - when we build an application that uses the "Core PPL's" and loads the "Developed PPL's" above, in order to use the PPL's from the centralised "ProgramData" location a configuration file was provided to define the path to search for the PPL's it uses as well as selecting "Exclude dependent packed libraries" in the build specification. The output executable functions correctly, loading in the plugins, however the moment you distribute this to anywhere other than the output folder (with the configuration .ini file). It opens with a broken run arrow...


Problem Solving:
The following are some of the things we have attempted to solve our issues this far:

  1. Relative Paths - PPL's that are built that have dependencies on other PPL's will maintain a relative path between the two, so long as you maintain this relative path you can distribute as required. This aids us with output location as we can distribute directly to "ProgramData" or "Public Documents" from the packed library build spec and move based on bitness appropriately 
  2. LabVIEW Search Paths - provide LabVIEW search paths alongside the default ones for finding VI's, this has no impact as the project seems to keep relative paths to dependencies anyway
  3. Application (.exe) Configuration File Search Path - as far as I can tell, adding the "ProgramData" bitness specific location to the ini file for the application seems to have no effect on the behaviour, works if it is or isnt there and similarly immediately breaks if you move the application from the output folder. It is almost like it stores relative paths.

 

Resources:

The following resources are ones we are aware of and have used for our attempts to solve this issue:

 

0 Kudos
Message 1 of 1
(281 Views)
Reply