02-11-2013 06:34 PM
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:
These would get honored during the package install process.
Would this resolve the issues that both Jack and Ton describe?
02-14-2013 09:49 AM
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
07-25-2013 09:21 AM
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:
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