Reuse library dependency & file management?

[OneOfTheDans]

I've searched high and low, but cannot wrap my head around reuse in LabVIEW. Hopefully someone can provide their insight, or direct me to documentation on the right way to manage all this

Our shop has less than 5 people that use LabVIEW, and we use it as a lab automation tool. The lab computers are each used for a variety of test programs. We're commonly tweaking the code during lab debug, so we run programs in development mode rather than using a built exe.

We use SVN to version-control our projects, and are comfortable using svn-externals. Our user.lib and instr.lib folders are synced across all machines. I haven't used VIPM, but it doesn't look like the right tool for our problem. It's purpose seems to be installing packages to user.lib or instr.lib. That gives machine-level control of library packages, but we need project-level control. Am I misunderstanding what VIPM offers?

Most top-level programs use common libraries that we've developed. I think the core of the problem is that some of those libraries also depend on each other. For example:

lib2 uses lib1

proj1 uses lib1

proj2 uses lib2 (and thus lib1)

proj3 uses lib1 and lib2

Problems:

1. proj2, proj3 must place lib1 in the correct path relative to lib2. How do they know where that is? How does this scale to many more libs?
2. lib2 should not contain lib1. Otherwise proj1 grows to also require (unneeded) lib2, and proj3 includes 2 conflicting lib1.

Is there a known best practice solution to this? If not, what are you all using, what do you like about your approach, what would you change?

[crossrulz]

If you aren't using multiple versions of these libraries, I don't see what your problem is.  Just put the reuse libraries in user.lib and nowhere else.  Then use the ones you need.  The project will only load what is needed.

[OneOfTheDans]

Oops, not sure how I missed that in the question. We essentially need multiple versions of the libraries.The libraries evolve slowly to follow our project needs. This means library changes break older projects, unless we update all our software every time we change a library (not feasible).

I think we want some way to isolate projects on disk so that each project has a copy of whichever libraries/versions it needs. I'll try updating the original post to reflect this.

[crossrulz]

---

@OneOfTheDans wrote:

We essentially need multiple versions of the libraries.

---

This is where VIPM comes in.  With VIPM Pro, you can create what are called Package Configurations.  So you just store the configuration with your project and load that configuration when you are dealing with that project.  VIPM will uninstall and install packages that correspond to what you have in that VIPC file.

[OneOfTheDans]

I didn't know about Package Configurations, and they sound promising. Looks like you need Pro only to create them. But to have a local repository, we need Pro on all client machines? $$

Learning VIPM, creating packages, and updating our code will take some time. As an intermediate step, we're considering standardizing our file structure to keep all libraries as svn-externals at the top level of each project, and the source files in a sub-directory. See the example below. I think this will retain all relative dependency paths between libraries, and allow library development without breaking any projects.

# Library1 Dev

./lib1/lib1.lvproj

./lib1/source/[FILES]

# Library2 Dev

./lib2/lib2.lvproj

./lib2/source/[FILES]

./lib2/lib1/    <- svn-external to lib1/source/

# Project2 Dev

./proj2/proj2.lvproj

./proj2/source/[FILES]

./proj2/lib1/    <- svn-external to lib1/source/

./proj2/lib2/    <- svn-external to lib2/source/

[crossrulz]

---

@OneOfTheDans wrote:

But to have a local repository, we need Pro on all client machines? $$

---

You only need 1 copy of VIPM Pro to make the vipc files.  The community version can use them.