Developing a User Library

[robweaver]

I am working a developing a new user library and I would like to get some feedback on others' experiences, recommendations, and best practices for developing a flexible, easy-to-work with/manage user library. The major concerns regard the best way of structuring the user library. Should it be one giant project that gets placed in the user.lib folder? Should it be a bunch of smaller projects that are managed individually, for instance, one project per major sub-category in the user library? Should it be a bunch of smaller projects inside of one giant project? Should it just be files and no project? Should I use a vilib and project combination? Any thoughts/recommendations are greatly appreciated and encouraged.

Thanks,

Rob

[Hooovahh]

I could probably take a very long time to explain my experiences with reuse (I did write my thesis on it) but I guess the best answer would depend on how much time you have to invest in it, and how large you expect your user library to be.

If it is relatively small, I think you can get away with just having your reuse code in one giant folder that you copy to the user.lib folder.  This has pros and cons but generally just works, and doesn't take too much time to setup or maintain.  But there may be version problems.  Do you rev. the whole setup if you change one VI?  What if you need special patchs to work with some versions of LabVIEW?  Are there going to be different repositories for each version?

If you go with the modular approach then you can group like components into packages using VIPM (package building is in the community edition).  Then you will have a series of files, one for each type of application (one for string, one for array, etc) and have dependencies between them, where maybe a File I/O depends on a custom Error package.  This also has pros and cons.  Where every developer will need to install VIPM to install the packages.  This is a tool any LabVIEW developer should be using anyway.  This approach is more complicated than the previous and will take more time to setup and maintain but the benefit is you can install only needed packages, as well as have configuration management for maintaining version dependencies.

Then you could build something custom.  Basically making a VIPM like tool.  Tons of time involved but fits your individual needs.  I would not recommend this one.

[F._Schubert]

I have never thought about placing everything in a single location. Every functionality get's it's own folder (error, queues, boolean controls,...). The more-fine grained, the easier to work with (versioning, releasing, creating the palettes).

Also consider that you need to place stuff in other locations as well: tools, templates, instrument drivers...

If your budget permits, spend some money on one of the commercial VIPM editions.

If I weren't stuck with 7.1., I'd also head for the (free) unit testing framework from JKI. Alternatively use the unit testing framework from NI.

Felix

[Hooovahh]

---

@f. Schubert wrote:

I have never thought about placing everything in a single location. Every functionality get's it's own folder (error, queues, boolean controls,...).

Felix

---

I was still talking about every functionality get's its own folder but I meant like this:

<user.lib>\Company\String

<user.lib>\Company\Boolean

<user.lib>\Company\...

But instead of managing each sub folder (String, Boolean, etc) just manage the whole Company folder and rev. it when any change is made.  Again it is easier to setup, but when your library is huge and you have dependencies issues with specific versions of LabVIEW it becomes a pain to manage.

[F._Schubert]

Hooovahh, I didn't ment to disagree with your first posting, but supporting it.

But using svn I can work on part2 of my lib and find an error on part1 of my lib: Correct the error and check in the part1 folder right away, while I don't check in the part2 folder as it's unfinished work there.

Felix

[robweaver]

Thanks for the input so far. I'm looking to stay away from any third party software to manage this library and I definitely agree that I would use a sub-folde organization strategy as mentioned:

<user.lib>\Company\Array

<user.lib>\Company\Boolean

<user.lib>\Company\Numeric

...

But I guess the question I'm still trying to answer is the selection of what LabVIEW organization structure I should use?

Some of the options I've considered are:

1. one .lvproj that organizes the entire user library

- this keeps everything contained in one location and allows for using user.lib VIs in other user.lib VIs if needed, but it could become a frankenstein project

2. multiple .lvproj where each sub-folder within the user library has its own .lvproj or a variation on this that groups the sub-folders into say a "Programming" project that has Array, Numeric, Boolean, etc. and an "Instrument" project

- this helps alleviate the fear of the frankenstein project and could help with managing the user library, but makes re-use within the user library a little more difficult. It also helps with distributing portions of the user library if needed

3. multiple .lvlib within a .lvproj where each sub-folder has its own .lvlib

- i'm not very experienced with .lvlib and had a tough experience when i tried to create a set of drivers as an .lvlib and then place that in my user library

4. multiple .llb within a .lvproj

- llb doesn't give the benefit of sub-folder organization, but it could be an option

5. other?

Any suggestions?