ColinR Posted October 21, 2014 Report Share Posted October 21, 2014 Hello, VIPM 2014, LV2012. VIPM builds are aborting due to library vis that it claims are open. This occurs with multiple libraries that were previously successful. LabVIEW is closed prior to build attempt. Mass compile on all files prior to build is error-free. Things I have tried: Restart, deletion of AppData temp files VIPM reinstall Removal and reinsertion of vis from library Open and close of vis outside of library Thanks, Colin Link to comment Share on other sites More sharing options...
RocketHacker Posted October 28, 2014 Report Share Posted October 28, 2014 i've ran across this and never was able to distill it down to a root cause. i know that it has something to do with having dependencies outside of the package source folder. i was able to successfully work around it by: create project for source files put source files into that project build source distribution of source filesadd source files to always included section in source file settings, put dependencies in support directory. apply name prefix to prevent name spacing issues later [*]build vi package from source distribution this sucks because it adds an extra step. i was annoyed by this until i realized that i had wasted about 20 hours trying to get it to work initially. the extra 5 min to do the source distribution is way less painful. but, seriously, jki needs to fix this bug. i'd give more details about what causes it, but even after 20 hours of mucking with it i still have no idea what triggers it to do this. Link to comment Share on other sites More sharing options...
ColinR Posted November 3, 2014 Author Report Share Posted November 3, 2014 i've ran across this and never was able to distill it down to a root cause. i know that it has something to do with having dependencies outside of the package source folder. i was able to successfully work around it by: create project for source files put source files into that project build source distribution of source filesadd source files to always included section in source file settings, put dependencies in support directory. apply name prefix to prevent name spacing issues later [*]build vi package from source distribution this sucks because it adds an extra step. i was annoyed by this until i realized that i had wasted about 20 hours trying to get it to work initially. the extra 5 min to do the source distribution is way less painful. but, seriously, jki needs to fix this bug. i'd give more details about what causes it, but even after 20 hours of mucking with it i still have no idea what triggers it to do this. Indeed. It has been two weeks with no resolution. Fortunately, I was able to move a vi that was apparently causing problems into the only library that actually needed it, which allowed me to build my package for my customer. I still have, however a library that has been updated that I cannot package. I have four libraries waiting for release because this will not build and they are interdependent. I have tried rebuilding the library, project, and vi from scratch with no satisfactory solution. I have been informed that JKI has been able to rebuild the library from source, yet received no suggestions for what I can do to resolve the issue on my end. I have tried reinstall of the version of LV and VIPM that I'm using with still no success. The only thing different is the installation of another version of LV on the same computer, which I suppose could potentially cause linking from another vi.lib, which would line up with some sort of crosslinking issue across versions, but I've nothing in my dependencies outside of vi.lib. I do have links in several vis to vis in other libraries it depends on, but this is a requirement for my application and a very basic feature requirement: the point of being able to specify dependencies is that there are dependencies on other installed libraries. Colin Link to comment Share on other sites More sharing options...
ColinR Posted November 19, 2014 Author Report Share Posted November 19, 2014 The issue and its cause: Library A would not build. Library A had dependencies on Library B. This was not a problem for previous builds, and is not ultimately a problem. Library B had a recently introduced dependency on Library A. This was not intentional, and I'm not clear that this sort of interdependency /should/ be a problem, but it is. Putting the dependent Library B into its own project to observe dependencies and eliminating the recursive dependency on Library A fixed the problem. The moral of the story, don't build a library that has dependencies on another library that itself has dependencies on the build library. This causes the 'VI already open' error observed in the original post. Thanks Jim for helping me to resolve this issue. Regards, Colin Link to comment Share on other sites More sharing options...
RocketHacker Posted November 20, 2014 Report Share Posted November 20, 2014 brilliant! I'll look into my failed builds to see if i'm hitting the same issue. thanks! Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.