Packed library fails to build (missing SubVI) unless I add its members to a class.

[tavta]

Hi, 

when building my APILib.lvlibp, I get the error: "APILib.lvlib:APIMethod.vi:SubVI is missing", although all the code is there and project has no errors. APIMethod contains only one SubVI, which belongs to a HelperLib.lvlibp, which is loaded in the project and everything seems fine. Mass build also works, but not building a lvlibp or .exe.

Deeper:

APILib.lvlibp depends on these two packed libraries:

1. BaseLib.lvlibp, which is installed in vi.lib/
   • this lib contains BaseClass.lvclass; and 
2. HelperLib.lvlibp, which is installed in APILib.lvproj's folder structure, i.e. in /APILibsrcfolder/../ext.
   •   this lib contains some methods, of which some have BaseClass.lvclass as control (and some don't)

APILib.lvlibp uses a HelperLib.lblibp:HelperMethod.vi method. Both APILib.lvlib and HelperLib.vlib depend on BaseLib.lvlibp in vi.lib, which is the desired behavior. 

When building APILib.lvlibp, LabVIEW complains about a Missing SubVI and I know it's talking about HelperLib.lblibp:HelperMethod.vi. No errors in the project. BTW, this HelperMethod may or may not use BaseClass.lvlib, same problem in either case. 

If I put BaseLib.lvlibp in HelperLib APILib's respective /ext folders, APILib.lvlibp build is successful.

 .... this code is part of a plugin framework: all plugins build fine, but not libraries. Therefore, I put all the APILib’s methods under a class: APILib.lvlib/APILibClassTrick.lvclass, which inherits from BaseLib.lvlibp:BaseClass.lvclass (important). ... and then the build is successful 😞.  

I see this as a trick/workaround, because I'd like to avoid putting a bag of VIs in a class just to make it to compile... Other than them using BaseClass.lvclass, there is nothing classy about them :). I'd prefer to put them straight in a lvlibp or something like that. 

Is that possible? What am I doing wrong?

Many thanks,

Rok 

PS: example LV2018 code attached, put BaseLib.lvlibp to your vi.lib to get the same behavior.

[cbutcher]

Hi,

I suspect that your problem is relating to changing relative paths between different pieces of your collection of PPLs.

In particular, I think that the path that HelperLib.lvlibp expects to find BaseLib.lvlibp at is different to where APILib.lvlibp is searching (using relative, not absolute paths).

Mark Yedinak and Yinhui Chen gave a presentation about searching for paths with PPLs, specifically looking at development vs installed versions, at NI Week 2019.

A video is available on Youtube here: Effectively Using Packed Project Libraries.

Watching that might give you some hints as to changes you could make.

When I build PPLs, I have them all build into the same directory. Like you, I choose to set the "Exclude Dependent Packed Project Libraries" option, which is crucial to having this work correctly. All of my source code depends on the PPLs in the shared build directory.

In your case, that would give me something like...

C:\my\dev\directory\Base_src\base.lvproj (and source code)

C:\my\dev\directory\Helper_src\Helper.lvproj (depends on C:\PPLs\Base.lvlibp)

C:\my\dev\directory\API_src\APILib.lvproj (depends on C:\PPLs\Base.lvlibp and C:\PPLs\Helper.lvlibp)

C:\PPLs\Base.lvlibp

C:\PPLs\Helper.lvlibp (when this builds, it knows its target directory is C:\PPLs, and that it depends on code in Base.lvlibp in C:\PPLs, so it expects them to remain side by side)

C:\PPLs\APILib.lvlibp (as above, with 2 PPLs)

You can, if you want, move the PPL directory somewhere else, for example to C:\my\new\installed\path\PPLs\{Base,Helper,APILib}.lvlibp, but they have to retain the same relative paths.

As an aside, it is definitely possible to create a library with no classes, that depends on other PPLs, and builds successfully.