vi.lib classes and PPLs

[_carl]

I'm using a VIPM package in vi.lib.  It has classes in it.  (It's proprietary, so can't share code.)

I'm creating a PPL/.lvlibp/packed library that use this VIPM, and exposes some methods that expect class inputs from the vi.lib.  Ideally, end users could call use the vi.lib methods, and pass a class into one of the PPL methods.

However....the PPL will create its own internal copy of the class, and there will be a wire conflict because of this. Any suggestions for how I can get around this issue?  Is there even a way to do this?

(I've tried excluding dependent libraries, but the PPL still seems to make its own copy of the class.)

[crossrulz]

You have to choose which copy you want to use.  Either everything in the application references the vi.lib code, which will be incorporated into the exe when built into an application, or use the PPL.  You cannot use both for the exact reason you have just ran into (ie they are completely different classes).

[jyoung8711]

In the couple places where I've had to do this in the past, I will create a ppl of the vi.lib component.  Then in the calling PPLs, you can reference the vi.lib component PPL, and callers will then all play nicely together because they're all referencing the same "base" vi.lib component PPL.

(I've seen this done with the actor framework before, for instance)

The catch is that if the vi.lib class is not in a library, then you'll have to create one, and edit the vi.lib component... this is typically not recommended, as it can add confusion if you try to move the build process somewhere with a fresh LabVIEW install... it can also upset other projects that might reference that core vi.lib code.

There are workarounds to the above as well -- for instance I had a case where I was using some community code, and I forked the repository for that code to make the changes needed to support PPLs (VIMs, libraries, etc).  Then I rebuild the package.  Now I have a re-use package that I can use myself that meets my requirements, and can be easily installed.

[_carl]

> In the couple places where I've had to do this in the past, I will create a ppl of the vi.lib component.

Yep...that's what I had settled on for a solution here -- seems like the easiest path forward as I have access to the source for the vi.lib code. Since I'm using VIPM packages, I suspect I'll have to relink all other projects that rely on this VIPM to the new paths (now found in an lvlibp rather than an lvlib) once this update gets rolled out, but... not a big deal in my case, but would be rather annoying if this had wider distribution.