Feedback request - Packaging and distributing your project provider with VIPM

[vishots.com]

I'd like more feedback on the following since I'm actively working on implementing this for the next release of VIPM.

Considering the addition of the following switches in the package build process:

• Shutdown LabVIEW Before Package Install (yes/no)
• Start LabVIEW After Package Install (yes/no)

These would get honored during the package install process.

Would this resolve the issues that both Jack and Ton describe?

[TCPlomp]

Hello Michael,

I think that these items are sufficient.

However it should be made clear to the VIPM user during installation that LabVIEW needs to be restarted during the process.

What might be a good idea is to check if the files that cannot be copied have changed indeed (for me it was a third party toolkit (OpenG pipes)) that wasn't changed, so checking the MD5 of the files mght be a good idea.

Ton

[EricLM]

So I am having some problems building a project provider with VIPM pertaining to the forced compile of VIs as well as the creation of the system package.

My problem: I have VIs that call a DLL within the Providers folder structure so the evolution of my build process has been this:

1. Can't build in place within the Providers folder because of previously stated problems
2. Build outside LV with relative path reference to DLL. VIPM automatically creates a system package with no way to override.
   1. Need ability to distribute multiple unique copies of the DLL and decide at install time which one to reference, not just the one referenced at build time
   2. System package does not include the DLL's dependencies, so it won't work to begin with
   3. System package fails install every time anyway (not sure if the system package path is incorrect, but there is no install location in the system package spec file)
3. Build outside LV with absolute path reference to DLL in LV structure. This prevents the system package from being built, but:
   1. If a user installs VIP with the same version of LV (2010) that I used to build installed on their system, all VIP installs (in 2012 say) will reference the DLL in the build version (2010) directory. Beyond the obvious problems this presents, I actually need the ability to have different DLLs installed for different versions of LV.
4. Build outside LV with absolute path reference to DLL in LV structure, but remove the referenced DLL before VIP build. For some reason, even though the VIs search for and find the DLL relative to their path (outside LV), it does not trigger the system package build in VIPM.
   1. Hooray, this does not create the system package (maybe because the VIs were not originally saved with the relative path reference?)
   2. On install, the VIP VIs now have a relative path reference the DLL, so each unique install references the DLL in that version of LV only.
   3. The problem with this is that editing these VIs now becomes cumbersome. I must have the DLL installed in the LV folder structure to edit, but then remove for build and they must be edited outside of LV. And I have to ensure that they are always saved with the correct absolute path reference. And this has to be scripted properly because I run some of these VIs pre-/post-build.

I am glad that I have found something that works, but I don't like how I got there. Accidental engineering is not what I enjoy doing. So, I have two requests and a question.

A. Please, please let users override the system package creation during build. I understand the intent, but I don't think all the use cases were thought about. What if someone is trying to package a driver or wrapper for a DLL and wants to build outside the LV folder structure? Isn't this a common occurence? In that case, the DLL would not be installed alongside the VIs. Why does this force the DLL to be installed in the system directory? Also, most higher level DLLs have dependencies, and without those being included in the system package, this feature simply would not work.

B. Please, please let users override the check for broken VIs/compile during build. This would also solve the problem (presuming VIPM would not look at dependencies), but also let broken VIs be included in the VIP. Yes there are good use cases for that (provider builders). I would have no problem with still getting warned by VIPM about the risk of not compiling even after disabling this. Just let us do it.

C. What if I manually remove the system package and references to it from the VIP after build? I don't like this, but it is starting to look like it may be less of a hassle than #4 above.

VIPM is a great way to distribute add-ons, but it is making the build process increasingly cumbersome as I want to add features. Including just a few power user switches would go a long way to alleviate some of these problems.

Sorry for the dissertation.

Thanks for considering