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

[WavePacket]

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

[FireFist-Redhawk]

What is the advantage to having your sublibrary within the other libraries? Could you give a little more detail about what your libraries are meant for, both sub- and super-?

[WavePacket]

---

@FireFist-Redhawk wrote:

What is the advantage to having your sublibrary within the other libraries? Could you give a little more detail about what your libraries are meant for, both sub- and super-?

---

I was anticipating (though unverified) that this would simplify the distribution of the "superlibrary" to devs.

For example, sublibrary would be a hardware class and superlibrary would be an actor which delegates to the hardwareclass. Depending on the project that the other dev is working on, they might need one or the other. I was thinking it would be natural to have the actor library include the library of the hardware class.

Maybe I'm wrong?

[FireFist-Redhawk]

My thinking would be that the libraries should stay as separate libraries.

One answer to the titular question Why does a "sublibrary" need to know which libraries its included in? is that VIs from the sublibrary are able to access/use the private VIs of the superlibrary. But in order to know which private VIs it can use, the sublibrary needs to know all libraries that it is a part of.

If your objective is to make distribution easier, I would suggest getting VIPM and start playing around with making packages in there (if you haven't already). It's free and easy to use and makes distribution a breeze.

[WavePacket]

---

@FireFist-Redhawk wrote:

...

One answer to the titular question Why does a "sublibrary" need to know which libraries its included in? is that VIs from the sublibrary are able to access/use the private VIs of the superlibrary. But in order to know which private VIs it can use, the sublibrary needs to know all libraries that it is a part of.

...

---

Ah, I didn't know there was almost an "inheritance like" aspect to libraries. 

---

@FireFist-Redhawk wrote:

...

If your objective is to make distribution easier, I would suggest getting VIPM and start playing around with making packages in there (if you haven't already). It's free and easy to use and makes distribution a breeze.

---

Well, I'm not sure this is an option for my particular workplace. How could I replicate the distribution behavior of VIPM using just native LabVIEW functionality? For example, I would like to archive some kind of distribution and place in on the network for someone to drag to their local computer. 

---

@FireFist-Redhawk wrote:

My thinking would be that the libraries should stay as separate libraries.

...

---

So each time that I start a new project which needs the superlibrary, I have to manually drag in all its sublibraries? That's probably not that big of a deal to be honest, I was just hoping to drag in one file and start programming. 

[FireFist-Redhawk]

---

@WavePacket wrote:

---

@FireFist-Redhawk wrote:

...

If your objective is to make distribution easier, I would suggest getting VIPM and start playing around with making packages in there (if you haven't already). It's free and easy to use and makes distribution a breeze.

---

Well, I'm not sure this is an option for my particular workplace. How could I replicate the distribution behavior of VIPM using just native LabVIEW functionality? For example, I would like to archive some kind of distribution and place in on the network for someone to drag to their local computer. 

---

---

I honestly don't know what to tell you there. The biggest advantage of VIPM is its GUI for arranging things in the palettes, so you don't have to "drag in" anything, it's all right there on the palettes when you start a fresh project. You can get things into the palettes without VIPM, using Tools > Advanced > Edit Palette Set..., but I'm not well versed in that.

---

@WavePacket wrote:

---

@FireFist-Redhawk wrote:

My thinking would be that the libraries should stay as separate libraries.

...

---

So each time that I start a new project which needs the superlibrary, I have to manually drag in all its sublibraries? That's probably not that big of a deal to be honest, I was just hoping to drag in one file and start programming. 

---

You shouldn't have to drag in your sublibrary, it should just exist somewhere where the superlibrary can access it (maybe instr.lib if it controls an instrument). And in that case, we are no longer talking about sub- and super-libraries but two "separate" libraries, one using VIs from the other.

[WavePacket]

---

@FireFist-Redhawk wrote:

...

---

You shouldn't have to drag in your sublibrary, it should just exist somewhere where the superlibrary can access it (maybe instr.lib if it controls an instrument). And in that case, we are no longer talking about sub- and super-libraries but two "separate" libraries, one using VIs from the other.

---

So as I'm developing the superlibrary, I drag the subvis of the sublibrary that are needed? And when I develop a new project, I just drag the superlibrary in?

[FireFist-Redhawk]

Yes.

[WavePacket]

After some more thought, I kind of have this worry that if I start dragging VIs from one library into another library, that I'm breaking encapsulation and setting myself up for additional work later. This kind of coupling between libraries is OK?

[billko]

---

@FireFist-Redhawk wrote:

My thinking would be that the libraries should stay as separate libraries.

One answer to the titular question Why does a "sublibrary" need to know which libraries its included in? is that VIs from the sublibrary are able to access/use the private VIs of the superlibrary. But in order to know which private VIs it can use, the sublibrary needs to know all libraries that it is a part of.

If your objective is to make distribution easier, I would suggest getting VIPM and start playing around with making packages in there (if you haven't already). It's free and easy to use and makes distribution a breeze.

---

I've found even the free version of VIPM is a super-powerful distribution package manager.  Create your won palette menus, all kinds of stuff.  The pro version lets the menu items show up on that right-click list you get when you click on something, but that's just icing on the cake.