LabVIEW
Building backsaved packages with VIPM
I'm trying to create my packages for LabVIEW 2016, but have (partly accidentally) moved the files to 2017. My understanding is that to create a package that can be installed in 2016 (or older) the VIs/libraries/... must be saved for 2016 (or older - omitted in future for brevity).
When I backsave the source for packages which depend on other installed packages I have written, they create two folders, one of which is a copy of ...\LabVIEW 2016\user.lib\... This is understandable because the page describing backsaving instructs readers that all files will be backsaved except those in vi.lib, or features that require the/a newer version of LabVIEW.
This brings me to the first questions - by default, packages created in VIPM install to vi.lib. Is this why? I had thought that since I was creating user packages, they should really install to user.lib. Should I go back and move them all to vi.lib, in order to allow backsaving? Or is there another way?
The second question is, does anyone have good recommendations for backsaving projects for building? Ways to improve a workflow here? My guess is that by having a parallel directory for only backsaved VIs, I can update the sources for the vipb file to reference the backsaved files, and then so long as I always remember to backsave before I build, I can keep things reasonably well in line.
I tried to get an account on the JKI forums to post this there, but I can't seem to get a verification email...
I remember there being an article that basically said to stop using user.lib, reuse code should go into vi.lib or instr.lib. I am unable to find it now. But if you already have things deployed to user.lib, just keep doing it since it would not be worth the effort to change.
As far as backsaving, I have a VI for that. Don't remember where the original was, but this is an updated version. It works well for VIs. It does projects, but not particularly well considering it will backsave all of the VIs as well (duplicate files flying around).
I've still been using user.lib, adding the underscore before the folder name so it doesn't show up in the User Library palette automatically. Not sure if there is a benefit over using one versus the other.
@crossrulz wrote:
I remember there being an article that basically said to stop using user.lib, reuse code should go into vi.lib or instr.lib. I am unable to find it now. But if you already have things deployed to user.lib, just keep doing it since it would not be worth the effort to change.
Was this (Developing a VI Based API) the article you meant? I seem to have, in light of your comment, found a bunch of different articles or documents from various periods of time which suggest different installation paths from {vi,user,instr}.lib choices.
I'll take another look tomorrow at just deleting sections of the backsaved project and trying to update their links (from .../packages/source/myProject/Program Files (x86)/National Instruments/LabVIEW 2017/user.lib/Company Name/myDependencyProject/blah.vi) , along with ensuring they're excluded from the VIP file.
@cbutcher wrote:
Was this (Developing a VI Based API) the article you meant? I seem to have, in light of your comment, found a bunch of different articles or documents from various periods of time which suggest different installation paths from {vi,user,instr}.lib choices.
This might have been it: File and Folder Names for Integrating into LabVIEW
So both documents say I shouldn't be using user.lib for what I'm using it for, okay well it is what it is.
