Hi Guys, I have a question somewhat related to source code control of libraries when they are included in multiple other libraries. After developing many LabVIEW libraries, I'm finding that I want to include some of them in other LabVIEW libraries. When I include a library as a sublibrary (for lack of a better term that I know about) within another library, it seems that the sublibrary's code knows about what other libraries its included into. As an example, when I then subsequently try to open the sublibrary, and if it can't find the library that it's include into, then it will ask for its location. This seems fine until I want to distribute the sublibrary to other devs., because then I need to give them the sublibary that they want but also including all possible other superlibraries -- which rapidly becomes unwieldy. Can someone point out my flaw? It seems that there really should be a better strategy. Thanks, -wavepacket

Yes, that is the general idea. PPLs can use other PPLs but they do not include other libraries within it. Libraries simply use PPLs. As mentioned earlier though you have to be careful at maintaining the calling hierarchy so that you don't get circular references to the libraries. And building the PPLs must be done from the bottom up for the overall build to be correct. There are two ways of thinking about the distribution of PPLs. One, is that each application would include any PPLs that it uses with its distribution. If you have multiple applications that you distribute that will be installed on a single machine then you would have duplicate copies of the PPLs on that machine. Each application would include a copy of the PPLs it uses. This does make things a little easier if you have multiple versions of the PPL as each application will include the version it was built with. However, if you are working with plugins then this approach makes it harder to update all of the applications that use a shared PPL o plugin since all applications would need to get a copy of the updated PPLs or new plugins. The other option is to use a shared location for the PPLs and plugins. The downside of this is that it is difficult to support multiple versions of the PPL on a single machine. But it is easier to update all applications since there is a single location for the PPLs.

LabVIEW

Why does a "sublibrary" need to know which libraries its included in?

Solved!

A VM is pretty much a must, but not enough. The problems already arise from the fact that the PPLs need to get loaded into the Windows IDE for development of depending VIs. That totally and completely breaks the whole thing and is very difficult to untangle then. So you need at least a dummy plugin PPL compiled for loading in the IDE and then you run into problems when having both in a project at the same time. While LabVIEW can deal with VIs being loaded in multiple contexts and has some working measures to deal with shared libraries, it is not fully prepare with the fact that you have two PPLs with the same name but different architecture loaded at the same time, not even if they are in totally separate projects. It somehow sees that the names are the same, and kind of considers them the same and then gets entangled in its own spider web of cross references.

There is a mechanism in LabVIEW that would promise to solve it. It's called path roots and allows to have multiple different directories for vi.lib, user.lib, and similar directories that LabVIEW resolves according to the actual target architecture. It is complicated and a bit crude around the edges but would be a useful solution. Except that some of the RT targets for whatever reason have that broken. So when you setup such directories in vi.lib and friends the only way to get the resulting executable to even load under NI Linux RT for x64 is to create some crazy symlink that maps the badly resolved path back to the effectively existing path on the target. The same thing surprisingly works fine on NI Linux RT for ARM. It also seems to be problematic on desktop Linux and Mac. The whole thing looks and feels like something that someone added for a specific need in a grey past, then it was forgotten and never looked at again when new targets were added. It just almost works but not quite!

Rolf Kalbermatter
My Blog