Jump to content
Sign in to follow this  
ColinR

VIPM Aborts build on 'open' vis

Recommended Posts

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

Edited by ColinR

Share this post


Link to post
Share on other sites

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 files
    • add 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.

Share this post


Link to post
Share on other sites

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 files
    • add 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

Share this post


Link to post
Share on other sites

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

  • Upvote 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
Sign in to follow this  

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.