Preferred approach to deploying instr.lib drivers

[rolfk]

I usually have a drivers directory in my source code control tree. In here I put any library that is needed by the project. In the past I have several times switched between expecting them to be in the according instr.lib, user.lib and vi.lib directories and set them up accordingly in project subdirectories and to simply refer to them from within the source code tree directly.

Both have advantages and disadvantages.

Copying them back to the according LabVIEW directories on start of (re)work of a project

+ can be directly referenced from the palette

- potential version conflict with other existing versions used in a different project, so you have to basically clean out those directories each time you go back to a project to work on

- extra work needed before starting to work on a new project

- extremely cumbersome if you have to maintain multiples different projects in parallel 

Leaving them in the project source tree in dedicated directories

+ no setup work required before starting to work on a project other than checking out the source code

+ any changes made to the drivers during development of the project are automatically committed with the project sources

+ if someone else needs to checkout the sources to work on, all he has to do normally is to setup the standard LabVIEW environment as documented in the top level text file with correct version number and additional required Toolkits, everything else is ready for inspection and work after checkout

- can't reference them through the palette but have to go always to the disk location or make them present in the project tree and drag from there

Since we tend to program on many projects over the course of a year, the second option is almost always preferable nowadays for me.

[Gryffin]

Sorry to bring up an old topic, but I had to deal with this today and am somewhat happy with the solution, so I figured I'd share!

I use Git to version control my LabVIEW project and wanted to maintain the functionality of the palette (i.e. still be able to select instrument driver VIs from the palette), but also backup the instrument drivers in my repo so that one could clone in with minimal fuss.

To do this, I:

1. Had my instrument drivers all in my "C:\Program Files\National Instruments\LabVIEW 2024\instr.lib" folder
2. Had my project already synced with Git
3. Closed LabVIEW entirely
4. Created a folder in my LabVIEW project directory called "Official Drivers"
5.  Moved all contents of "C:\Program Files\National Instruments\LabVIEW 2024\instr.lib" to "C:\projectFolder\Official Drivers"
6. Opened an admin command prompt (Win11 shouldn't require admin) and moved to "C:\Program Files\National Instruments\LabVIEW 2024\" folder
   1. cd "C:\Program Files\National Instruments\LabVIEW 2024\"
7. Made a symbolic link/junction in the "C:\Program Files\National Instruments\LabVIEW 2024\" folder called "instr.lib" which points to "C:\projectFolder\Official Drivers"
   1. mklink /j "C:\Program Files\National Instruments\LabVIEW 2024\instr.lib" "C:\projectFolder\Official Drivers"
8. Bingo!

Now, I simply add, commit, and push with git, and all drivers are backed up! Meanwhile, LabVIEW is working well with this link and new drivers *should* install in the "Official Drivers" folder.

This, of course, makes the "Official Drivers" folder the driver folder for ALL of LabVIEW (fine in my case), but probably not for others. I would simply make "instr.lib" its own git repo if I needed more flexibility.

Also note, if someone cloned into the repo, they would first have to create the symbolic link in the "LabVIEW 2024" folder for things to work smoothly.

Hope that helps someone!

[Gryffin]

One problem was putting it in my project folder...

I moved "Official Drivers" one directory up and made my repo a folder containing "Official Drivers" and "projectFolder".

Then, it worked as desired.

[billko]

I like using VIPM (not NIPM).  It makes deploying libraries so easy.  It makes an installer that you just double click on.  Much more functionality beyond that, too.  Custom icons, custom palette.  For a modest fee, you can include it in the VI right-click replace menu.

[OneOfTheDans]

That's a cool way to do it Griffin! You could even include little scripts that change the symlink to point to your active project. This seems like a very good one-developer solution.

I've ultimately settled on VIPM like billko. But unlike him I find it clunky to create all these projects and .vipbs just to get simple drivers deployed. VIPM is a good de facto standard though, so more people can be involved without me needing to onboard everybody how to correctly map a network drive or symlink to Google Drive or explain how SVN externals work, and how to peg revisions...

[billko]

---

@OneOfTheDans wrote:

That's a cool way to do it Griffin! You could even include little scripts that change the symlink to point to your active project. This seems like a very good one-developer solution.

I've ultimately settled on VIPM like billko. But unlike him I find it clunky to create all these projects and .vipbs just to get simple drivers deployed. VIPM is a good de facto standard though, so more people can be involved without me needing to onboard everybody how to correctly map a network drive or symlink to Google Drive or explain how SVN externals work, and how to peg revisions...

---

I chose that path for the exact same reason.  It's easier for users to deploy.  But like you said, it's kind of clunky to use.

[cordm]

---

@Gryffin wrote:

One problem was putting it in my project folder...

I moved "Official Drivers" one directory up and made my repo a folder containing "Official Drivers" and "projectFolder".

Then, it worked as desired.

---

Just a thought: It sounds like you could make use of the LVAddons feature, see the wiki or this thread.

You could set a LVAddons.AdditionalLocations path where you keep your dependencies. That folder could be version controlled and then you could check out different versions according to the project. I haven't done any of that but it sounds like a neat way to keep track of dependencies. Although I can see myself abusing that system and gradually create a monster repository with all my reuse stuff.