bug VI Package Builder reports "friends" (community scope) as missing

[Joerg Hampel]

With the latest version of VIPM (2021.0 build 2696), the VI Package Builder reports friends of a library as missing even though those friends are not used in the code that's built.

Quote

"Friend libraries are allowed to access community scoped members of the class that's being built. However, the class being built does not actually depend on these friends -- actually, it's the other way around." (Jim)

In the small example I attached, I created a class "TheClass.lvclass" which has one method "SomeSharedFeature.vi" which is set to community scope. Another class "TheFriend.lvclass" uses this method, and is therefor defined as friend in "TheClass". All the LabVIEW files are located in the /source folder.

I created a source distribution to export "TheClass" to another place, a folder named /build (mainly because the original project where this error occurred does the same). 

When I use "community-scope.vipb" to build a package, everything works as expected. But when I remove or rename the location of "TheFriend" (eg rename /source to /___source),  then VI Package Builder complains about missing files:

 

 

community-scope.zip

[Jim Kring]

Thanks for taking time to post a good example. We did tighten some things up in 2021 that now results in VIPM finding some dependencies that it were not previously found — specifically, 2020 and earlier would not find dependencies inside of broken VI‘s, disable structures, or code that gets compiled out. However, it appears that we are now pulling in these edit-time Friend classes that aren’t really dependencies. Will take a look and see how we can address is. Thanks.

[Jim Kring]

I just checked the code and, indeed, it was this change (to included Edit Time Dependencies) that caused the friend class to get identified as a dependency.

I think there's a possible solution -- when reading the linker info one can pass an Exclude Edit Time Dependencies.  When this is set to TRUE, then Friend classes are not included in the linker info. I think this will work, since I just confirmed that Parent classes are returned in the linker info, regardless of whether one sets Exclude Edit Time Dependencies to TRUE or FALSE, so I think one can effectively determine a Friend relationship by getting the linker info twice (once with the flag set to TRUE and once with it set to FALSE) to determine if the Edit Time Dependency lvclass is a friend or a parent.  I can't think, off hand, of any other types of lvclass relationships that would show up in the linker info of an lvclass other than Parent and Friend.  Can you?

PS - The example you submitted didn't have a .dragon file in it

[Joerg Hampel]

8 hours ago, Jim Kring said:

PS - The example you submitted didn't have a .dragon folder in it

😅

Thanks for looking into this. I'm not an LVOOP expert at all, so when I say "I can't think of any other types, either" it doesn't mean a lot I fear.

[Jim Kring]

Update: We should have a fix for this in the next build.

[Jim Kring]

There's a new build of dragon that fixes this issue and allows packages with Friend Classes to build correctly. Download it here.

[Sergio Anaya]

Hi,

I am using VIPM 2022.0 (build 2371). My latest build failed due to a 'missing' source code from openg_string.lvlib (OpenG String Library 6.0.2.35), which turns out to be a FRIEND of the library.

I wonder if there is a VIPM setting somewhere that I am missing.