Jump to content

Q: Importing dependent libraries in a package build?


Daklu

Recommended Posts

(The question arose while I was composing this message on Lava.)

 

I'd like to automate the process of importing dependent libraries into a package during the build process. Users don't need to know about the dependent libraries, so I'd like to make them private members of the library I'm actually building. I figured a pre-build script should do the job, but I realized it might not be possible.

 

As I understand it VIPM creates a separate app instance and copies the source code during the build process. If I follow the steps outlined in my post on Lava, will the resulting package contain and link to the private reuse code, or will it end up linking to private reuse code that now is part of my source code library? (I vaguely remember running into a similar issue a while back with ogpb.)

 

Thanks,

Dave

Link to comment
Share on other sites

[Cross-posted to LAVA]

 

I have posted this before I think but here is how I do it:

 


  •  
  • Start with a LabVIEW Project
  • Create a top level Project Library that is used to namespace my distribution
  • Add a virtual folder to the LabVIEW Project called support
  • Add all the reuse VIs that will be made private to it, normally done by dragging and dropping from the dependencies item in the LabVIEW Project
  • NI Builder assign the support folder to a Project Library during the build process
  • Run my build script that adds the support Project Library to top level Project Library
  • Then makes the support Project Library a private member of its parent (top level Project Library)
  • Now all the VIs in the support folder are private to the distribution and namespaced so they won't collide with the actual reuse VIs under <LabVIEW>

 

Currently this workflow is for NI Builder + OGPB, but I am wanting to move it to VIPM 2010.

I think it shouldn't be an issue, all I have to do is handle adding the support VIs to a Project Library as part of a script - all the rest I already have code for.

But I am interested in anyones else's thoughts

Link to comment
Share on other sites

I have posted this before I think but here is how I do it:

 

[*]Add all the reuse VIs that will be made private to it, normally done by dragging and dropping from the dependencies item in the LabVIEW Project

I may not be understanding your process correctly, but this step worries me. If you're importing the classes residing in your reuse directory to a project-specific library, your reuse code--which is supposed to be independent--becomes dependent on that project-specific library. I suppose you could do the build then remove the reuse library from the project-specific library, but in the meantime the namespace changes to your reuse code has reset the mutation history of any classes in that library. That can be big problems for other users and other applications.

 

Until NI gets around to separating namespacing (and mutation history) from library membership there may not be a good way to reliably handle what I'm trying to do. Even what I proposed has limitations to what end users can do with the new reuse package.

Link to comment
Share on other sites

I may not be understanding your process correctly, but this step worries me. If you're importing the classes residing in your reuse directory to a project-specific library, your reuse code--which is supposed to be independent--becomes dependent on that project-specific library.

 

It says "LabVIEW Project" not "LabVIEW Project Library" - moving reuse VIs into a LabVIEW Project (.lvproj not .lvlib) will not have any effect.

Link to comment
Share on other sites

It says "LabVIEW Project" not "LabVIEW Project Library"

Yep... I was misunderstanding your process. :blink:

 

Can you clarify a couple more steps for me? I'm not quite sure I'm following what you do.

 

"NI Builder assign the support folder to a Project Library during the build process"

 

I take it you create a Source Distribution build in the project? I don't see a way to directly assign a virtual folder to a project library during the build. It (as far as I can tell) can only be done for an entire destination directory. Do you send all your reuse code in the Support virtual folder to the Support build destination (or custom destination), and assign all the Support destination content to a new library?

 

So if my reuse library was named Messaging.lvlib, now it will be Support.lvlib:Messaging.lvlib, correct?

 

"Run my build script that adds the support Project Library to top level Project Library"

 

Now the private reuse code has the MyPackage.lvlib:Support.lvlib:Messaging.lvlib namespace, right? I think this will do what I'm asking for. I do wish I didn't have to trash the mutation history of the messaging library, but there's not much we can do about that.

Link to comment
Share on other sites

Sorry for the stupid questions. But I have to start somewhere. huh.gif

  • These dependent libraries, you talk about. Are they beneath vilib?
  • Have they already been packaged and installed using VIPM?

If the answer to the above is YES. Then I think you can just remove them as dependancies during the VIPM package build process and VIPM will automatically suck them into the package and do the relinking for you.

 

One thing it won't do however is mark the library VIs private. sad.gif

Link to comment
Share on other sites

Sorry for the stupid questions.

Totally NOT stupid questions!

 

 

  • These dependent libraries, you talk about. Are they beneath vilib?
  • Have they already been packaged and installed using VIPM?

If the answer to the above is YES. Then I think you can just remove them as dependancies during the VIPM package build process and VIPM will automatically suck them into the package and do the relinking for you.

Yes to both questions... I'll have to try that out.

 

One thing though, does VIPM suck the dependent libraries into the *package* or into the *library* I'm deploying with my package? And if it just sucks them into the package, doesn't that leave me with two publicly accessable copies of the same library (possibly with slightly different implementations) installed in vilib? Or does VIPM automatically do some namespacing magic on the dependent libraries on it's own?

Link to comment
Share on other sites

I think this is a really interesting discussion and I think some pictures may help so I will post some more when I get home.

 

Or does VIPM automatically do some namespacing magic on the dependent libraries

 

Namespacing magic - it will (re)namespace the reuse VI's with the package name (or at least it did in 3.0).

 

Can you clarify a couple more steps for me? I'm not quite sure I'm following what you do.

No probs! Sorry, let me try again :)

 

I take it you create a Source Distribution build in the project? I don't see a way to directly assign a virtual folder to a project library during the build. It (as far as I can tell) can only be done for an entire destination directory. Do you send all your reuse code in the Support virtual folder to the Support build destination (or custom destination), and assign all the Support destination content to a new library?

 

I assign the "Support Virtual Folder" to the Project in my workspace (not in the building process).

I manually drag and drop in the dependencies I want. OpenG? JKI? MGI? My Library? etc... Anything I don't include will become a real dependency (configured in VIPM)

 

So if my reuse library was named Messaging.lvlib, now it will be Support.lvlib:Messaging.lvlib, correct?

 

"Run my build script that adds the support Project Library to top level Project Library"

 

Now the private reuse code has the MyPackage.lvlib:Support.lvlib:Messaging.lvlib namespace, right? I think this will do what I'm asking for. I do wish I didn't have to trash the mutation history of the messaging library, but there's not much we can do about that.

 

Most likely - the reason is that I would normally distribute a package like that as a real dependency - the process described here is for reuse VIs and making them privately scoped however, I think it would be fine with the library, but as you pointed out (here and other places in the community) you would kill the mutation history which is not what you like to do (each time you build the version gets reset etc...)

 

On a side note, in order to translate this process from OGPB to VIPM I may need a list of VIs that have been renamespaced during the build but there is no "Project and "Support Virtual Folder" in the VIPB file to keep track of things. Off the top of my head, I could read the Project and get the list, then mangle the new name, this may work.

Link to comment
Share on other sites

One thing though, does VIPM suck the dependent libraries into the *package* or into the *library* I'm deploying with my package? And if it just sucks them into the package, doesn't that leave me with two publicly accessable copies of the same library (possibly with slightly different implementations) installed in vilib? Or does VIPM automatically do some namespacing magic on the dependent libraries on it's own?

VIPM sucks dependancies, which have not been defined as external, into the package automatically. Not into any LabVIEW library. It does auto-namespacing and relinking of those VIs for you. For namespacing we use a GUID.

 

Yes, those namespaced VIs are publicly accessible. As I mentioned earlier. We don't have any ability currently to make them Private. However, this would be a feature we could consider if you find it useful.

 

One of the motivators for us to have VIPM pull-in dependancies into the package (when not declared as external) was to make it easier for people to distribute their reuse package. This would allow you to give someone a single package, with no dependencies, install it, and it would work right out of the box. Of course, the end user could dig into the vilib folder and find the dependancies if they wanted to. Best practices dictate that you should only use what's in your palette right? wink.gif.

 

It seems like your need is finding a way to protect the dependancies from end users in a more controlled fashion.

 

Why is it important to maintain the mutation history?

Link to comment
Share on other sites

[Cross-posted to LAVA]

 

I have posted this before I think but here is how I do it:

 

  • Start with a LabVIEW Project
  • Create a top level Project Library that is used to namespace my distribution
  • Add a virtual folder to the LabVIEW Project called support
  • Add all the reuse VIs that will be made private to it, normally done by dragging and dropping from the dependencies item in the LabVIEW Project
  • NI Builder assign the support folder to a Project Library during the build process
  • Run my build script that adds the support Project Library to top level Project Library
  • Then makes the support Project Library a private member of its parent (top level Project Library)
  • Now all the VIs in the support folder are private to the distribution and namespaced so they won't collide with the actual reuse VIs under

 

Currently this workflow is for NI Builder + OGPB, but I am wanting to move it to VIPM 2010.

I think it shouldn't be an issue, all I have to do is handle adding the support VIs to a Project Library as part of a script - all the rest I already have code for.

But I am interested in anyones else's thoughts

 

Jon,

 

This sounds really cool! I'd love to see this in action with VIPM 2010. The one issue I see is that VIPM 2010 is that your script would be modifying the sources of your VI Package, prior to the build. This could create a sticky situation...

 

  • Are you going to create a post-build script that reverts the changes to the sources?
  • If you revert the changes, what happens if you have uncommitted changes already in the sources?
  • Would your pre-build script require that there be no uncommitted changes in the sources?

Another option is to do the entire build process on a copy of the sources. That gets tricky too...

Link to comment
Share on other sites

VIPM sucks dependancies, which have not been defined as external, into the package automatically. Not into any LabVIEW library. It does auto-namespacing and relinking of those VIs for you. For namespacing we use a GUID.

 

Yes, those namespaced VIs are publicly accessible. As I mentioned earlier. We don't have any ability currently to make them Private. However, this would be a feature we could consider if you find it useful. <snip>

 

It seems like your need is finding a way to protect the dependancies from end users in a more controlled fashion.

Ahh... I didn't know VIPM did this.

 

My primary goals are:

1. Eliminate dependencies between packages as much as possible, and

2. Avoid namespacing conflicts.

 

Importing the dependencies into the package's library seemed like the most logical way to do that, but what you've done solves the problem too. Thanks for the tip!

 

At the moment I don't have a pressing need for the dependent libraries to be private. Mainly it's to prevent boneheaded mistakes like having users accidentally link to the dependent library by draging and dropping from an open block diagram. (No, I'm not speaking from personal experience... I have no idea what you're talking about. :unsure: )

 

 

Why is it important to maintain the mutation history?

Because I'm not ready to open the can of worms of writing custom serialization and mutation methods for all my classes.

 

As an app developer I can analyze the specific requirements and focus on serialization/mutation code for a few classes that need to be persisted. As an api developer I don't know what other developers will want to do with the components I've created, so I assume someone will need to persist the component's state to disk. Stepping on the dependent objects' mutation history while building that package make it harder to allow users to do that.

 

My package source can't use the read/write to disk prims directly on the objects, so I can try manually decomposing all the dependent objects into their native data types and save those instead. Not only is that a pain, but it makes client code dependent on implementation details that are better kept private, and if any data is private it won't work.

 

So since using the read/write prims isn't an option, and decomposing the object isn't an option, that leaves me with writing serialization methods for all my public objects. If a library's namespace could be changed and the mutation history preserved (and I was really careful with my coding) I could at least avoid writing serialization methods for data-only classes (those with no references) and still guarantee forward compatibility for users.

Link to comment
Share on other sites

Jon,

 

This sounds really cool! I'd love to see this in action with VIPM 2010. The one issue I see is that VIPM 2010 is that your script would be modifying the sources of your VI Package, prior to the build. This could create a sticky situation...

 

  • Are you going to create a post-build script that reverts the changes to the sources?
  • If you revert the changes, what happens if you have uncommitted changes already in the sources?
  • Would your pre-build script require that there be no uncommitted changes in the sources?

Another option is to do the entire build process on a copy of the sources. That gets tricky too...

 

Hi Jim

 

I see three options (if there are anymore please point out)

  1. Pre-build: Editing the source - I don't want to be editing the src, that would be a headache as you pointed out.
  2. Post-build: Unpacking/repacking - I don't know if unpacking/repacking the zip and editing the src is going to be any easier.
  3. Pre-build: Make a copy, edit and point VIPB to it - but if VIPM can't see the code until its created with a script, then I am sure it will flag an error. This could possibly be solved using programmatic access to VIPM from LabVIEW i.e. create/build/edit/prepare the VIPM code first, then launch VIPM so any prechecks won't fail. Coincidently this is what I do with OGPB.

 

The more I look at it, the more harder it seems :)

But I am still keen to get it to go if possible.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...

Important Information

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