\t\t\t\tMy inbox has been filling up with emails from those of you who have been eagerly awaiting this follow-up to the previous post.\u00a0 Okay, so the truth is that I went on a post-NIWeek 6-week vacation and am finally back at work. [Or perhaps Nancy was doing the other part of her job… helping customers be successful through face-to-face interaction.–ed.]<\/p>\n
In the last post, we looked at the typical use cases and benefits for Packed Project Libraries (PPLs).\u00a0 However, as the Field Architects have been working with customers, we ran into a few issues.<\/p>\n
We are faced with a design challenge when working on large projects with multiple Packed Project Libraries (PPLs), specifically layers of libraries. We need to understand how PPLs link to other PPLs when a hierarchy of PPLs exist. \u00a0Let’s look at an example…<\/p>\n
<\/p>\n
Public Method.vi and Private Method.vi are members of the library A.lvlib. \u00a0When A.lvlib is added to a project, these owned VIs appear as well. Below, we have 3 files: A.lvlib, Public Method.vi, and Private Method.vi.\u00a0 The project library has a link (or reference–technically, the library is an XML file that lists the VIs and their location) that establishes the connection to the methods:<\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0
<\/p>\n
Once we compile A.lvlib to A.lvlibp, the PPL,\u00a0 we now have one file that contains, and not just references, all of the Exported VIs (former Public Methods):<\/p>\n
<\/p>\n
\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0
<\/p>\n
We may continue to add PPLs as needed to our application:<\/p>\n
<\/p>\n
Dilemma of a Hierarchy of PPLs<\/strong><\/p>\n Our problem arises when, as is usually the case, we develop a hierarchical organization of libraries or PPLs.\u00a0 Let\u2019s assume that A.lvlibp calls B.lvlibp and both are independently called by Main.vi.\u00a0 One might argue that A calling B and Main calling B is bad design.\u00a0 This design consideration should probably be the topic of a future blog post. \u00a0Regardless, this structure isn’t uncommon. \u00a0If we assume that B is a PPL of analysis functions, it is reasonable to assume that it might be called by more than one other PPL.\u00a0 It could be called by a PPL that measures data as well a PPL that reads data from a file.\u00a0 So our use case is as follows:<\/p>\n Let\u2019s examine the multi-step process of compiling B.lvlib into a PPL.<\/p>\n We begin by compiling A.lvlib into a PPL called A.lvlibp.\u00a0\u00a0 B.lvlib calls functions in A.lvlibp and\u00a0 as such is linked to A.lvlibp.\u00a0 One might assume that I could compile B into a PPL such that it is linked to the original compiled A.lvlibp.\u00a0 Alas, that is not the case.\u00a0 B.lvlibp treats its dependent A.lvlibp as a source file and creates a copy at a new location.\u00a0 At the conclusion of this process, we now have two copies of A.lvlibp.\u00a0 One resides in the original location in which it was created and the other resides in a new location.<\/p>\n Having two copies of A.lvlibp on the hard disk is arguably problematic, though this is the intended behavior of the PPL build process.\u00a0 When distributing an application, the executable and its dependencies are distributed together. \u00a0This happens because of limitations in LabVIEW’s ability to dynamically search for and link to PPLs.<\/p>\n Is the PPL Source or Compiled?<\/strong><\/p>\n A.lvlibp is indeed compiled code.\u00a0 However, for the purpose of creating a second PPL that calls or is linked to A, it is treated as a \u201csource file.\u201d Note that the original A.lvlibp is not source code, rather a source file for the PPL.\u00a0 Therefore when the compiled B.lvlibp is built, A.lvlibp is treated as a support file and must be copied to a second destination.\u00a0 That is how we arrived at having two copies of A.lvlibp.<\/p>\n So Now What?<\/strong><\/p>\n The developer of Main.vi is now in a quandary with multiple copies of library A residing on disk. Can Main.vi call the original A.lvlibp and B.lvlibp?\u00a0 No; that causes a conflict of filenames.\u00a0 B.lvlibp is linked to the second A.lvlibp. We would then have a conflict in the project with two separate instances of A.lvlibp:Public Method.vi residing in two locations.\u00a0 So the way we handle this conundrum is to treat the original A.lvlibp as it is intended.\u00a0 It is the \u201csource file\u201d for B.\u00a0 We must plan and determine the destination of the final A.lvlibp, defining a sensible file structure for the developer of Main.vi who will use both A & B.\u00a0 In the above illustration, all PPLs called by main, regardless of hierarchy, reside in one folder.<\/p>\n What Else?<\/strong><\/p>\n In the above use case, each PPL has a specific responsibility.\u00a0 Many PPLs may be called by Main.vi.\u00a0\u00a0 Each can be updated with a new version, independent of the other PPLs.\u00a0 If a bug is found in either A.lvlibp or B.lvlibp, only the affected PPL must be retested and redeployed.\u00a0 However, multiple copies of the PPL will exist and, as noted above,\u00a0 the software development process should be designed appropriately to account for this.<\/p>\n Another Design?<\/strong><\/p>\n Another option is to organize the libraries first.\u00a0 Remember that .lvlib files can be nested.\u00a0 B.lvlib (pre-compiled) can be a member of A.lvlib. The final and single PPL can be a compiled wrapper around the entire hierarchy.<\/p>\n So in this use case, one person might own the development, test, and maintenance of Library A.\u00a0 Another developer may do the same for B.\u00a0 Then instead of creating two PPLs, the entire hierarchy is deployed as one PPL.\u00a0 The benefit is that only one PPL exists and we no longer have multiple copies.<\/p>\n The downside is that we now have one monolithic PPL. If the end user is only using one or two VIs out of a library of hundreds, then this is not an optimum solution, as the load time will be longer.\u00a0 However, if the user will be using most of the PPL, then the load time issue is unavoidable.<\/p>\n What Do You Think?<\/strong><\/p>\n Several of us differ on our preferred organization of layered PPLs so we\u2019d like your input.\u00a0 Additionally, what issues still remain for you as you leverage PPLs in LabVIEW 2011?\u00a0 What could be changed to make PPLs more useful for you in 2012?\t\t<\/p>\n","protected":false},"excerpt":{"rendered":" My inbox has been filling up with emails from those of you who have been eagerly awaiting this follow-up to the previous post.\u00a0 Okay, so the truth is that I went on a post-NIWeek 6-week vacation and am finally back at work. [Or perhaps Nancy was doing the other part of her job… helping customers […]<\/p>\n","protected":false},"author":3,"featured_media":129,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_post_was_ever_published":false},"categories":[4],"tags":[43],"class_list":["post-214","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-programming","tag-labview-packed-project-libraries-lvlibp"],"yoast_head":"\n<\/p>\n
<\/p>\n