update/replace PPL in project, PPL versioning

[littlesphaeroid]

I can't find a consistent easy way to replace a packed project library in a project. If I update/rename/reconfigure a packed library, how can I get VIs in a project file to reference the new library?

As a wider discussion, how does one go about versioning PPLs such that the latest version is ensured to be in use by executables and other libraries?

LV2014

[tyk007]

1) I have found the search/replace functionality possible but also time-consuming. Architecturally the best approach is to keep your PPL public API consistently hidden behind an abstraction in your calling code-base. This limits the locations where you might need to make changes should the PPL interface change.

2) You are really looking at a build configuration chain through a build server such as Jenkins, TeamCity etc. These tools have the notion of chains or dependencies such that a new build of a module triggers the build of dependent client code-bases. LabVIEW NXG has some native support for this through the "modules" container which can be linked as dependencies to actual build specifications.

[littlesphaeroid]

Thanks for this interesting reply. I'm particularly interested in this:

'Architecturally the best approach is to keep your PPL public API consistently hidden behind an abstraction"

Can you give an example of how to do this? I have done this in essence for one module, and found it useful because I could also allow for modifications to the library name (versioning the name to ensure the latest library is in use). But in that case the calling executable doesn't need to know anything about the modules being called. In the case where I"m calling public members of an API, I'm not understanding how to access those in a PPL without having the PPL loaded into the executable's (or other PPL's) project.

[tyk007]

Basically keep calls to your PPL API wrapped in a set number of VIs in your calling code - they can pretty much mimic the PPL public API unless you see an advantage in changing it to better integrate with the client codebase. Then the rest of your code only refers to these VIs. This limits the changes to within this wrapper if you change your PPL API. You still need to reference the physical PPL binary though.

You mentioned something about versioning and PPL filenames. What I do in these sort of situations is:

• PPL filename always remains the same (it is checked into source control after all)
• PPL version is based on source control versioning where possible (eg. 'build' value set based on SVN rev). This allows me to track down the codebase of the PPL if bugfixes are necessary. I have a build server to do this automatically whenever the PPL source is committed but developer diligence could do the same. You could also ensure that the library version automatically increments - there is a tickbox for that.
• PPL always contains a "Get Version" VI which interrogates the library at runtime to obtain its file version.

A lot of people have tried plug-in style architectures with PPLs. You could have a read of these:

• https://forums.ni.com/t5/LabVIEW-Development-Best/Plug-in-Architecture-using-Packed-Project-Librarie...
• http://labviewjournal.com/2011/10/packed-project-libraries-part-2/

[littlesphaeroid]

Thanks for this! I have already implemented a plug-in architecture, but I am now dividing up the non-plugin parts of the code to see if this sort of modularity would be helpful for development/build time/etc.

For example, I have a set of global variables, and these are now in a PPL, accessible to the main application and to plugins. This is great, but now sure how I would abstract this, other than to create a read-write method on every variable in the global.

I am still attached to the idea that library names should be able to change, for example Global 1.0.lvlibp, Global 1.1.lvlibp. I find this very helpful for plugins, both for the end user and the calling program: there's a clear way to identify the newest version of the plugin. But for a module tht is not a plugin, but a core component, I am still trying to wrap my head around what to do.

Thank you for the links. I'm studying!

[tyk007]

If your PPL names are going to continuously change then hiding the calls within wrapper VIs is the best way to go. It doesn't alleviate you from the burden of changing the calls (if they are statically linked) but it minimizes it.

I do encourage you to consider using the file version of the PPL instead of filename if possible. An end-user can always right-click, properties and read the file version of the PPL, just like dlls; calling code can do the same through that "Get Version" VI or just getting the windows file version metadata directly.