packed project libraries

[PaulL]

OK, someone needs to start a thread on this new feature in LabVIEW 2010. Who has tried it and with what results? How does one work with packed project libraries most effectively?

---

I considered this one of the more promising features of LabVIEW 2010, since we have large collections of reusable code that we realized we needed to put into project libraries. It would additionally be helpful indeed to build each piece only once (per change), which was the promise of the packed project libraries.

The obvious application for us to try this on was one that took 40 minutes to build and consisted of a small application that talked to a large existing collection of code (in classes) used elsewhere. I assembled the reusable large portion into a library in one project and built it, included the referenced build in the calling project (OK, this was a nightmare--the lesson learned is to put your code properly into project libraries before attempting to reuse it!), and built the calling application. The build took... 40 minutes. Using packed project libraries didn't help at all as far as the build time goes. On the other hand, using packed project libraries does mean the dependencies of the called .lvlibp files are hidden in those libraries rather than in the top-level dependencies. I should also note that I built debuggable files. I didn't strip the diagrams, which certainly could make a difference.

Another thing we noted is that if we build nonLabVIEW files (e.g., configuration files) when we build a sublibrary, we have to include those files as well in the build definition for any callers if we want to include them in the destination directory for the caller's build. Moreover, the caller's destination directory includes a copy of the sublibrary builds as well, which I understand because it makes it easy for the caller to find them and be sure to have the correct version, but it does mean that if you rebuild a sublibrary you have to then rebuild the caller (that is, if you want to reuse the new version) or copy the newly built sublibrary wherever it is used (which I understand will be legal if the interface hasn't changed). This presents a bit of a maintenance problem. Probably the easiest thing is to rebuild every caller in a hierarchical fashion, but right now we don't have a tool to facilitate that process. We have to be savvy maintainers or build our own batch build tool. (We attempted to get around this by putting all the builds in the same directory but LabVIEW won't build the caller if its dependencies are already in the destination directory. NI already thought of that and defeated it.)

So... have packed project libraries been useful to you? If so, in what way? How do you handle maintenance issues (making sure you have the right versions of the packed project libraries where you want them)? Do you just stick with project libraries unbuilt (with which you may have only a single copy!)? Do you use project libraries at all? (Not so long ago we didn't much at all but my current thinking is they are critical to facilitate effective code management.) What best practices have you learned to share with the community of LabVIEW developers and, of course, advanced virtual architects?

[Daklu]

So... have packed project libraries been useful to you?

Haven't tried them out yet.

Do you use project libraries at all?

Absolutely. All my code is in a library of some sort... either a lvlib or a class. Usually a class inside a library.

What best practices have you learned to share with the community of LabVIEW developers and, of course, advanced virtual architects?

- Use lvlibs to divvy up your application into modules; it helps keep your code organized. As an added bonus libraries make it a little easier for multiple developers to work on the same project. Much less fighting over who gets to checkout the .lvproj file.

- Make liberal use of privately scoped classes inside a lvlib. Typically a module has too much functionality to fit inside a single class. Break the module's functionality into separate classes and make them private. Expose the needed higher level functionality through a few public api classes. Your modules will be much easier to use.

- Tight coupling within a module = good. Tight coupling between modules = bad (usually.)

- If you persist your classes objects to disk, don't change their namespace... ever. That resets all the internal mutation data.

- Give your libraries descriptive names. Letters are cheap... don't be a scrooge.

- Always, always, always be aware of your dependencies between modules. Avoid cyclic dependencies.

[jgcode]

I considered this one of the more promising features of LabVIEW 2010, since we have large collections of reusable code that we realized we needed to put into project libraries. It would additionally be helpful indeed to build each piece only once (per change), which was the promise of the packed project libraries.

The first time I heard mention of PPLs (beta), I thought it would be a cool way to distribute my general reusable component code, exposing only the public VIs and having everything that is private, hidden and locked away.

However (as Jim pointed out to me then), as you are compiling the PPL for a specific target and LV version, so it is not (general) reusable friendly.

Therefore, I see the PPL being used within an single platform Application to speed up the build time and compliment the changes to the compiler that now result in a greater build time.

So reuse in an Application context, not in a general context would be a role.

I can also see benefits of it with RT, i.e. downloaded one file, instead of many.

However, I have not dived deep into this feature yet (we am still on LV2009 anyways) but am interested to hear other user experiences.

[PaulL]

- If you persist your classes to disk, don't change their namespace... ever. That resets all the internal mutation data.

You are correct that this is currently the situation but I think I should comment on this issue because it troubles me--greatly. So what follows is an aside on that topic. Caveat lector! :-)

{It certainly is true right now in LabVIEW, but it shouldn't be as bad as it is. [The worst part, in my experience, is that LabVIEW won't let you correct the problem--or more accurately some manifestations of it--in any reasonable fashion. Right now a LabVIEW class converted to be inside a library will show up in the dependencies (when called in another project) when an external caller VI includes a class constant or control of that class, and, worse yet, even if one clicks Load and points LabVIEW to the class file on disk, it won't load the class and fix the problem. So, yes, if you have a lot of such calls think twice--or thrice--before changing the namespace!]

Note that UML/Enterprise Architect does not have this problem--even between projects. (OK, there may be a way to force the issue but in practice it doesn't happen.) This is because of the way EA handles the links between elements. LabVIEW could use this model between classes (and probably in principle LabVIEW's model is not so different, just not fully or correctly implemented). (OK, the tricky part is in the relationships embedded in the code of the method calls themselves, but I think this is not really all that different. Actually, we know it's not, since if we resave a linked file within a LabVIEW project all the callers update correctly. So the sort of relinking I am envisioning is quite possible.) (If we had a full-featured UML tool with forward and reverse code engineering, we would just restructure the relationships in the model, then rebuild the code. ) This could be--and should be--easy as pie. Why are we as application developers thinking about file paths at all? (I suggest with a bit* more work on LabVIEW itself this would be totally unnecessary.) I suggest--by no means a hard number but an educated guess--that such an effort would reduce our development time by ~70%. That would be an awfully good return on the investment!

[*Disclaimer: I don't know how large the bit is but given that the technology readily exists elsewhere I don't think it's really all that much. In fact, I think the first part is in the realm of bug fixes in LabVIEW right now.]}

Of course, I have addressed these issues in other threads so I will let it go at that. At the present moment the reality is that changing namespaces when there is a caller in another project will result in broken callers and lots of extra work to fix formerly working code (I just spent the last week plus doing just this), so, yes, do this sparingly.

- Give your libraries descriptive names. Letters are cheap... don't be a scrooge.

I completely agree, except that one can actually run into the situation where there are long file names that LabVIEW (or the O/S) can't handle, so letters aren't quite totally "free." (We actually moved our working directories closer to the drive root a few months ago to avoid that situation.) Of course I am assuming that you reflect your library names in your file structure--which isn't strictly necessary but I expect is standard practice.

[Daklu]

You are correct that this is currently the situation

You're commenting on a different problem than the one I intended to highlight. You're talking (I think) about dev environment behavior. I'm talking about run-time behavior. There's another thread on the topic here. I should have said, "if you persist your objects to disk."

Of course I am assuming that you reflect your library names in your file structure--which isn't strictly necessary but I expect is standard practice.

QSMs are standard practice too and you know what I think of THAT convention.

I do generally keep my libraries in directories of the same name. However, the library's directory tree doesn't reflect the class hierarchy. Each class directory is a direct subdirectory of the library directory regardless of where it falls in the library's code structure. Also, each class directory is flat--I don't create subdirectories to separate the sub vis. I've found a flat directory structure makes it easier to refactor my code since I don't have to move files around on disk as roles change. I've never run into the problem of having a path that is too long.

[PaulL]

You're commenting on a different problem than the one I intended to highlight. You're talking (I think) about dev environment behavior. I'm talking about run-time behavior. There's another thread on the topic here. I should have said, "if you persist your objects to disk."

Oh! Well, I completely misunderstood, then. Thanks for the link to the other thread (which for some reason I had completely missed!). I'll have to read that thread carefully.

I do generally keep my libraries in directories of the same name. However, the library's directory tree doesn't reflect the class hierarchy. Each class directory is a direct subdirectory of the library directory regardless of where it falls in the library's code structure. Also, each class directory is flat--I don't create subdirectories to separate the sub vis. I've found a flat directory structure makes it easier to refactor my code since I don't have to move files around on disk as roles change. I've never run into the problem of having a path that is too long.

We use essentially the same approach you describe for our file structure. Part of the problem was we started in the My Documents folder, and then had the version control folders and so on before we ever got to the code. Then we encountered long file names when we tried to do a Save As.... Since we moved everything out of My Documents we've been OK.