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

[FireFist-Redhawk]

@WavePacket wrote:

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?

---

Properly scope every VI/control in each library and I feel like you should be good.

[Mark_Yedinak]

All I can say is that I think you are doing something wrong. Our applications consists of nearly 200 libraries with a calling hierarchy about 12 levels deep and non of our "sub-libraries" know or care about calling or "super-libraries". We have even built all of these as packed project libraries.

I suspect that you have circular references or bad dependencies. Meaning, your sub-library is using some VI or typedef from a super-library. When creating your reuse libraries you need to be very careful what external resources they use. We often create API libraries which are generally nothing more than a collection of typedefs. This API libraries acts as a break between the library itself and callers. Think of the API libraries as header files in C. Their purpose is simply to define the data structures. This is particularly useful in messaging based systems. If you are doing re-use libraries you need to make sure that they are very well defined, constrained and limited in scope. If you start nesting your reuse libraries you need to work from the bottom up. No sub-library should ever use an typedef or VI from a higher level library.

Think of level 1 being the most basic set of libraries. Level 2 is the next layer and so one. The rule you need to follow is that Level(N) libraries can only ever include or call Level(N-1)libraries. They may never call peer libraries of higher level libraries.

[FireFist-Redhawk]

---

@Mark_Yedinak wrote:

All I can say is that I think you are doing something wrong. Our applications consists of nearly 200 libraries with a calling hierarchy about 12 levels deep and non of our "sub-libraries" know or care about calling or "super-libraries". We have even built all of these as packed project libraries.

I suspect that you have circular references or bad dependencies. Meaning, your sub-library is using some VI or typedef from a super-library. When creating your reuse libraries you need to be very careful what external resources they use. We often create API libraries which are generally nothing more than a collection of typedefs. This API libraries acts as a break between the library itself and callers. Think of the API libraries as header files in C. Their purpose is simply to define the data structures. This is particularly useful in messaging based systems. If you are doing re-use libraries you need to make sure that they are very well defined, constrained and limited in scope. If you start nesting your reuse libraries you need to work from the bottom up. No sub-library should ever use an typedef or VI from a higher level library.

Think of level 1 being the most basic set of libraries. Level 2 is the next layer and so one. The rule you need to follow is that Level(N) libraries can only ever include or call Level(N-1)libraries. They may never call peer libraries of higher level libraries.

---

I could definitely be wrong, but I believe the OP has a superlibrary of this form. And in this form, you can't add Sub.lvlib by itself to any project, you have to add Super.lvlib. If you try to add Sub.lvlib by itself by RC'ing "My Computer" -> Add -> File..., and selecting Sub.lvlib, it automatically adds Super.lvlib. 

Not sure who is talking about what at this point, but that was my impression of the problem. I am using LV17 SP1.

Spoiler

[Mark_Yedinak]

You are correct. The reason ours works is that they are built as packed project libraries. PPLs do break the cycle of the name spacing that is occurring which is why the super-libraries are getting pulled in. Their name space has been altered to include the super-library. If built as a PPL, it does not have this name spacing issue. Your post reminded me of why we went to PPLs years ago.

[WavePacket]

^That's my problem.

[WavePacket]

---

@Mark_Yedinak wrote:

You are correct. The reason ours works is that they are built as packed project libraries. PPLs do break the cycle of the name spacing that is occurring which is why the super-libraries are getting pulled in. Their name space has been altered to include the super-library. If built as a PPL, it does not have this name spacing issue. Your post reminded me of why we went to PPLs years ago.

---

I've never done a PPL before, but I suppose I might use this as a learning excuse. Any chance you have a resource to point a beginner to?

[Mark_Yedinak]

How about my presentation from NI Week 2019: Effectively Using Packed Project Libraries 

[WavePacket]

---

@Mark_Yedinak wrote:

How about my presentation from NI Week 2019: Effectively Using Packed Project Libraries 

---

So I'll admit that I only overviewed these slides, but at a conceptual level is this solution as follows:

1. Both libraries are placed in a project. The change of terminology away from sub and super is deliberate - as I'm understanding in this solution that we are no longer including libraries within libraries.
2. Build a PPL
3. Distribute the single PPL

PPLs seemingly fulfils my desire to distribute a single "something" to other developers, and keeps things encapsulated, right? 

[Mark_Yedinak · Accepted solution]

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.

[crossrulz]

---

@WavePacket wrote:

PPLs seemingly fulfils my desire to distribute a single "something" to other developers, and keeps things encapsulated, right?

---

That's one way I use them.  For instance, I have a PPL for common VISA actions and SCPI commands.  Most of these PPLs are fairly small, but I can easily distribute only what I need for a project and only compile an update for that library that got updated.

But PPLs are also extremely useful for plugins when combined with Object Oriented Design.  Think Hardware Abstraction Layer here.