Internal dependency ID string (used for renaming) breaks build

[jgcode]

I ran into the following problem the other day.

I was building a source distribution with the LabVIEW App Builder (not VIPM) and the .lvproj file included dependent VIs (from VIPM packages, as well as any of their internal dependencies too) in a virtual folder so that they can be included in the source-dist.

It happened after I updated a package and installed the latest version.

It went something like this:

 

I went to build some code and I got this error:

 

I checked my .lvproj (you can't see but these were in a Virtual Folder under My Computer NOT the Dependencies ProjectItem) and there was missing VIs - weird!:

 

I knew the package was installed so I checked the .lvproj's Dependencies and that's where I found the VIs I was looking for and also discovered the VI names had changed:

 

The dynamically changing names had broken my build!

Of course the workaround is that anytime I update this package I have to manually update the .lvproj.

 

Granted this use case might be limited however, my proposal is that the ID string (or whatever it's called) used to rename internal dependencies becomes a property of the .VIPB and is reused on subsequent builds (but if there was a need there should be a way to reset it - I cannot think of one at the moment). This would fix this issue.

 

Thoughts?

 

Regards

-JG

[Michael Aivaliotis]

I don't have a problem with allowing adjustment of this value. However I need to understand a little bit more about how this is a problem. Is the issue related to the next task which uses your source distribution? Does it depend on these names. And if so, why? I'm not following the workflow.

[jgcode]

Thanks for the reply Michael. Essentially I am working outside of VIPM here (woah! crazy I know ) and it breaks my code - I will try to explain better:

 

Lets say I have A.vi which was was installed via a VIPM package called Package A.

A.vi calls the following VIs Aa.vi and Ab[iD String].vi (all internal to the Package A).

However Ab[iD String].vi is obviously an internal VIPM dependency of Package A (that originated from another package but was included in Package A for whatever reasons etc...)

 

Now I am working with a new project (.lvproj) in LabVIEW, which has nothing to do with VIPM and my new VI 1.vi calls A.vi.

In order to create a source distribution of my new project, I add all the calling VIs to the .lvproj file.

As I am going to need to export: 1.vi, A.vi, Aa.vi and Ab[iD String].vi.

 

However (and this is where the problem is occurring) - if I build and install a new version of Package A then it's ID String of it's internal dependencies changes.

The next time I load the .lvproj file it cannot find Ab[iD String].vi and the source-dist build cannot run (broken).

If the ID String stayed the same, this issue would not occur.

 

Hope that makes things clearer?

 

In terms of the workflow I understand that Ab[iD String].vi (although not scoped) is a private VI that should not be called on any block diagram so it's name is irrelevant. This is still the case here however, it needs to be included in the .lvproj so I can create a source-dist of the code that does not have any dependencies (or rather can have selected dependencies).

 

Regards

-Jon

[Michael Aivaliotis]

I would argue that you don't need a source distribution. Just include the package and install it when necessary. The whole point of packages is to avoid source distribution chaos.

[jgcode]

I would argue that you don't need a source distribution. Just include the package and install it when necessary. The whole point of packages is to avoid source distribution chaos.

 

Well that is not always the case, for example - if you are building a tool to put on the LVTN and it includes links to your company's reuse library, you are not going to distribute your company's packages, it is more convenient to include those VIs internal to the package. Additionally I prefer creating/distributing tools that have no external dependencies.

 

As mentioned previously I am working outside of VIPM here, this was due to some issues that may have been resolved in an upcoming VIPM release - so I am eager to test it out