Yet another issue with vipm

[cirrusio]

Continuing on the VIPM is terrible thread - just ran into another time wasting issue that I can't figure out. I have

• created a project with the files that I am interested in building into package and found the the dependencies to be correct.
• opened every file to make sure that nothing is broken and even resaved the files after making some cosmetic adjustments to ensure that they save properly
• opened the files multiple times to make sure that there are no issues loading
• mass compiled the directory that I am trying to build into a package
• shutdown and restarted LabVIEW
• rebooted my computer
• deleted and reconstructed the build spec for the package

and yet I still get a dependency not satisfied issue as shown in the image below.  The file it is griping about was originally deployed to the location that it lists, but was redeployed to another location.  Given that LabVIEW has no problems with the VIs in the package and that there is no dependency to be found in the location in the error, this seems to be strictly an issue with vipm.  Does anyone have any thoughts about this?

[JÞB]

I'm just going to ask,  Did you see this link?

Some of your issues may be addressed there

[cirrusio]

I did not see this but no it doesn't answer my question.  Thanks though.

[Jacobson-ni]

Can you build an exe or source distribution from LabVIEW without running into this error? I have run into a few problems recently with builds having linking problems that don't seem to exist in development. If the same problem exists in a LabVIEW build there might be more options for debugging than a VIPB (I have very little experience making VIPBs so I don't really know).

[rolfk]

Do you really have a decimal point at the beginning of the "Generic TEC" directory???

[cirrusio]

So, the decimal point indicates a hidden file and is generated when VIPM begins a build to temporarily store files before packaging.  Someone with more behind the scenes access will have to explain why, but I suspect it is to check that it does indeed compile.

And as it turns out, I magically fixed this problem.  I

• did not change anything in the code.
• did not recompile
• did not add anything

What I did do was attempt to open the temporary files while it was doing it's thing (that rolfk points out) to see if I could determine why it seems to think there is a dependency on a non-existent file and viola! it worked.  And that only took me something like all day to figure out.  I wish (not really) that I could say that this is a solution, but I still have no idea why this error was thrown or why this would fix it.