Libraries, Packed Libraries, Source Code Distributions, and the End of the Universe

[mje]

Recently when I was in a discussion with a colleague of mine, the issue of packed libraries came up, and I’m getting a little nervous. A few questions:

What happens to namespaces? I have LibraryB.lvlib that uses classes from LibraryA.lvlib. If I make LibraryA into a packed library, do the inheritance chains in LibraryB all break because instead of LibraryA.lvlib:SomeClass.lvclass, I now have LibraryA.lvlibp:SomeClass.lvclass? That is can the packed library serve as a drop in replacement? It’s not too big of a deal if it can’t, I can go around and change all the classes this one time.

What happens if a packed library include the same VIs from another library which is also used by a project that uses the packed library? Say LibC.lvlib is used by LibD.lvlibp. If I then need both of these in my project, do I run into problems because ultimately two versions of some of LibC will exist? Or does namespacing prevent the ambiguity from arising (though at the expense of having multiple copies of the same VIs in different namespaces, which I might add can become very inefficient with common re-use objects)?

I see the benefits of packed libraries, but I’m also very skeptical that they won’t complicate the project or just make everything implode on me. After reading through threads like this one I get the impression I’m not the only one with some questions about these beasts.

I’m still having trouble convincing myself that packed libraries bring anything useful to the table that a normal library won't do-- or which won’t be offset by the headaches which will be caused . I’m looking to see if anyone will point out pitfalls that won’t be immediately obvious when I get around to at least trying to implement packaged libraries.

Thanks,

-m

[PaulL]

Yes, the namespace changes. Fortunately, LabVIEW 2010 does make the process easy for you--in one direction only. You can click on a project library (.lvlib) in a project and choose to replace it with a packed project library (.lvlibp). LabVIEW will update all the callers in the project. When I tried this it worked fine.

Note that LabVIEW 2010 does not support the reverse process (automatically replacing a .lvlibp with a .lvlib), so be sure you really want to do this before you make the change! (We have an open support case with NI to do just that. The AE wrote a scripting VI that does much of this, but it doesn't yet work for certain pieces.)

I'm not sure about your second issue (LibC.lvlib). When I built a packed project library that had dependencies on another library, I built the dependency into a packed project library first. (So all callers in a project would call LibC.lvlibp.) I'm not sure that in principle it would be appropriate to do otherwise, but I still would like to know the answer to your question.

In our case we found the following with packed project libraries in 2010:

1) Projects took much, much longer to open (20 minutes in one case!) after we replaced .lvlibs with .lvlibps. (Yes, the project mentioned was big but it didn't take nearly that long to open when we just had a .lvlib.)

2) Executables took just as long to build after we replaced .lvlibs with .lvlibps. (I think expediting build times would have been the main reason for using packed project libraries.)

3) We had circumstances where a contractor needed access to the source code anyway because they needed to modify shared variable properties for testing.

For these reasons (worse performance instead of better, lack of flexibility to revert callers to link to .lvlibs--which is exceptionally limiting and was in our case quite costly to fix, no benefits whatsoever), we managed to revert our .lvlibps to .lvlibs (the AE's tool got us most of the way) and have abandoned .lvlibps entirely, at least in their current instantiation. Honestly, I wish I hadn't wasted my time with packed project libraries as they are in LabVIEW 2010. That was just a big mistake on my part.

I'd love to hear what experiences others have had, good or bad, though.

Paul

[mje]

Thanks for the info, Paul.

Note that LabVIEW 2010 does not support the reverse process (automatically replacing a .lvlibp with a .lvlib), so be sure you really want to do this before you make the change! (We have an open support case with NI to do just that. The AE wrote a scripting VI that does much of this, but it doesn't yet work for certain pieces.)

I noticed as much. I switched to a packaged library and it went off without a hitch*. In addition to the inability to go back to an lvlib, I don't see a clean way to switch from say a debug version of the livlibp to a release version.

*Except for a pair of internal .cpp errors during the course of the build, but LV does that so often for me I don't feel like it's working right unless I see an error dialog in response to any arbitrary action beyond wiring or dropping VIs. But that's another story, and despite the errors, the packaged library does get produced and is usable...ish.

In our case we found the following with packed project libraries in 2010:

1) Projects took much, much longer to open (20 minutes in one case!) after we replaced .lvlibs with .lvlibps. (Yes, the project mentioned was big but it didn't take nearly that long to open when we just had a .lvlib.)

Yes! I'm finding the same. My project opens pretty snappy still, but when I open a VI to edit it, it is very slow. The entire IDE begins to crawl, to the point where window dragging becomes painful or even impossible in some cases. Not impressed.

For these reasons (worse performance instead of better, lack of flexibility to revert callers to link to .lvlibs--which is exceptionally limiting and was in our case quite costly to fix, no benefits whatsoever), we managed to revert our .lvlibps to .lvlibs (the AE's tool got us most of the way) and have abandoned .lvlibps entirely, at least in their current instantiation. Honestly, I wish I hadn't wasted my time with packed project libraries as they are in LabVIEW 2010. That was just a big mistake on my part.

I'm about ready to throw in the towel as well after only a few hours. The edit-time performance of the IDE is just plain unacceptable now that I've started dealing with the packaged library. I'm also concerned about switching out debug/release versions, or committing any changes since reverting to a normal library as you implied is not supported.

-m

[jdunham]

We just started using a packed library, for our XControl. We have an XControl which uses a lot of our library VIs, and so whenever that is on any open front panel (i.e. when the xctl is locked), you can't edit any of those subVIs, and that's a major pain. Once the XControl has been tested, you can make a packed library of the whole thing, and then a separate copy of the whole shebang will be running in its own context.

Unfortunately, it seems to have make dev environment run slower. It could just be stuff in our XControl, but the same stuff seemed to become more sluggish after the packed library was created, and there are more spikes in CPU usage while using the LV editing system. For us it's still worth it, but the performance hit is unfortunate, assuming it's really the cause of the lvlibp.

[PaulL]

I should reiterate that I think using project libraries (.lvlib files) is a very good idea. There are some issues with the implementation of project libraries as well, but they are quite helpful in managing code.