Nested Packed Libraries

[barney]

Hi there,

 

I had to use packed libraries (PPL). No problems... But then I also had to deploy my code with PPL's.
As already known there are several issues noted http://labviewjournal.com/2011/10/packed-project-libraries-part-2/?relatedposts_exclude=99 out there.

I wondered if there is a solution to this with 2013 but as far as I know : nope.

 

If somebody knows a good simple way please let me know.

 

While experimenting I found a way how to do it. I attached some code and am curious if it works for others too....

 

The setting was like this.

 

I had a LibC and it is used in LibA. In LibB I had to use LibA and LibC.

In the Main.vi I use LibA and LibB.

 

 

It's a usual use case I hope . A library LibC used by two plugin's.

 

Since Labview includes the lvlibp's in each distribution you run into a name conflict when using and deploying the lvlibp's and the exe in the end.

The solution would be to exclude them during build. But this wasn't possible. It seemed !

 

Naive as I am I had a look on the build specs in the project files, and found an node called "Bld_excludedDirectory" but only for source distribution. I copied this entry from there to the spec for the PPL and ..... it worked fine!

This came out at last.

 

<Property Name="Bld_excludedDirectory[0]" Type="Path">../Shelf</Property>
<Property Name="Bld_excludedDirectory[0].pathType" Type="Str">relativeToCommon</Property>
<Property Name="Bld_excludedDirectoryCount" Type="Int">1</Property>

 

So when the project is load into memory the build classes keep this info and proceed with it as with source distribution.

(One draw back is, that when resaving the whole project or edit the build spec in the editor it is gone again   ! )

 

It's now in principle also possible to have a custom exclude path for the build.

 

then I had doubts:  Am I doing something illegal? I hope no.....

 

I hope I could help someone with this Info.

 

Best Regards

Barns

 

LibALL.zip

Edited March 10, 2014 by barney

[Tim_S]

I don't have LV2013 installed, so I'm going on your text and the link.

 

I have something similar to the case you're describing. My use case is where "LibC" is a record object, and LibA and LibB are different types of plugins to the system. I think I avoided the issue you're having as my design uses a queue to talk between LibA and LibB. The typedef of the queue is not contained within LibA or LibB and only contains simple data types (string, boolean, numeric...).

 

I see two options for you: 1) evaluate your code's design and look at what needs to be where, or 2) merge LibA and LibB into a larger conjoined LibAB as the article you linked to suggests.

[barney]

Hi Tim_S,

 

thanks for the reply.

 

I'm running a project started in 2006  when GOOP was young. I used the endevo implementation and deployed every thing with source distribution and loaded dynamically.

I now started to change to the Labview objects and first tests improved speed. Objects are much more handy to deal with lot of functionality; I like it.

If you want to load objects dynamically you have to build them somehow, or capsulate them? Otherwise you will have a lot of vi's on your disk which I want to avoid.

But when deploying objects you get name conflicts when building because of the inheritance mechanism. (Same name for the dynamically overriding vi).

 

Also frameworks where developed using PPL's. https://decibel.ni.com/content/docs/DOC-19176#/; https://decibel.ni.com/content/groups/large-labview-application-development/blog/2011/05/08/an-approach-to-managing-plugins-in-a-labview-application

 

But what if you want to use PPL "plugin's" in PPL "plugin's"?  e.g. PPL Intrument drivers used by PPL plugins?

Or your PPL plugin's depend on one math library  [Main(LibA(LibC),LibB(LibC))] provided in a PPL?

And then build it in an exe.

 

 I'm not a "real" programmer so if I'm wrong please help me out...

 

I'll try to provide the zip for 2011.

 

Best regards

Barns

[Tim_S]

You have the right articles for building a plugin to be used in an executable. I recommend using packed libraries for this. To do this, you would have to:

1. Design your base "Parent" object in its own project. Build a packed library containing the parent object.
2. Design your executable in its own project using the parent object in the packed library. Use the method described in the articles to load the plugin at run-time.
3. Design your plugin in its own project using the parent object in the packed library.
   

Beware of linking to the source of the parent object in the executable or the plugin; this will create conflicts. The best way to eliminate the conflicts is to move the source code out to Never-Never-Land where the project won't find it, then load the project and start cleaning up the conflicts.

[barney]

Mmm, but this only works for one hierarchy level or? 

attached with version 2012....

I don't get conflicts at all.... ?? In this constellation??

LibALL_2011.zip

LibALL_2012.zip

LibALL_2013.zip

[Tim_S]

Yes, this hierarchy keeps you from crosslinking between packed libraries and source code, so no conflicts.

 

You can do this for multiple levels/ layers, but you have to make sure you don't loop backwards. LibA can use LibB and LibC, but you have problems when LibC tries to use LibA. Whatever you are compiling must not depend on something you're going to compile later.

[JackDunaway]

One answer, perhaps unsatisfying (or perhaps even impossible in your scenario) -- attempt to *not* link between PPL's in <LV2013, for practical reasons and heartache of which you are already intimately aware! Consider requesting access to the LabVIEW Beta Program (ni.com/beta) to evaluate new features and give your feedback there.

 

In the meanwhile, if you have source access to LibC from your original illustration, allow the builds of LibA and LibB to "suck in" dependencies from LibC as private, namespaced members of their respective libraries. This does represent duplication, but is an explicit, legit strategy for two reasons: 1) avoiding linker issues, both during build and run-time, and 2) allowing LibA and LibB to have two separate, decoupled dev cycles w.r.t. LibC, enabling them both to link to separate versions of LibC.

 

Generally, the same strategy applies to LibA -- decouple it from LibB at runtime if possible, sucking in those dependencies at build time.

 

Tradeoffs, yes -- but as a best-case scenario, you have source access to all libraries, and your business domain lends itself well to this strategy.

 

 

Naive as I am I had a look on the build specs in the project files, and found an node called "Bld_excludedDirectory" but only for source distribution. I copied this entry from there to the spec for the PPL and ..... it worked fine!

 

...

 

One draw back is, that when resaving the whole project or edit the build spec in the editor it is gone again

 

My hunch is that your "hacked" settings are preserved with any action other than explicit edits to the Source and Destination settings on the Build Spec, and generally you're fine except when editing these pages, but of course your mileage may vary for such "unsupported" modifications. I've found it useful to run a post-build Unit Test to check for anomalous linkages into areas where I don't expect -- this prevents embarrassing scenarios, of say, shipping a distro that links to something in a "Temp" folder on your user desktop 

 

 

[barney]

Thanks for the reply...

I run into another issue.

 

I tried to get it run with source distribution and llb's. When I do that and exclude a class a library or a vi, every subvi and control used by the members are also excluded?!

Is this a wanted behaviour?

 

Means. Every subvi and control used in the excluded lvclass, lvlib or vi is also excluded from the distribution?!

 

Regards

Barns

Edited March 13, 2014 by barney

[Tim_S]

I believe you are seeing expected behavior. To load from a source distribution, you have to include all files needed. By excluding, you are telling the source distribution build that those files are not needed. The files would have to be already present on the target system in the expected or findable location (such as user.lib if you're loading from the development environment) for this to work.

[barney]

Hi Tim!

Also the sub vi's from an excluded file?

regards

barns

Edited March 17, 2014 by barney

[Tim_S]

Yes, including the subVIs. The VI you're trying to load will be broken (not able to run) if anything the VI uses (or subVIs, subVIs of subVIs, etc., use) is missing.