Jump to content

Recommended Posts

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.

 

Relations.png
 
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

post-34118-0-94094800-1394455532.png

Edited by barney
  • Like 1
Link to comment

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.

Link to comment

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

Link to comment

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.

Link to comment

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.

Link to comment

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  :unsure:
 
 
Link to comment

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 by barney
Link to comment

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.

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.