Closed jimkring closed 1 year ago
Great discovery Jim, I didn't realise that was an option.
As you say, the search can just walk back up the path to check for a ppl.
Yes, this was a fun discovery we just made yesterday. We are exploring PPLs as a nice way to package up ci/cd tools (since PPLs pull in all external dependencies, which means they will be well-isolated from any VIs being called by the end user's application that's being built/tested).
We're looking forward to G-CLI support for this feature, so let me know if and when you need help testing :)
@JamesMc86 any chance we could get this into the 3.0 beta?
Why not! I'll take a look now, shouldn't be too demanding. I've also tested and see this also impacts LLBs (although I'm expecting that is less common)
Sweet! I’m gonna OU some VI tester fixes soon
LabVIEW.exe supports VI paths inside of PPLs, like the following:
This will open
run_me.vi
However, if I try to do this with G-CLI, I get the following error:
I would expect G-CLI to support opening a VI inside a PPL. Perhaps if there is a name that matches the pattern (*.lvlibp) anywhere in the parent folder hierarchy, then G-CLI can just assume it's a VI inside a PPL. Or, maybe there are some ways for G-CLI to detect that there is actually a VI located inside the PPL at that location -- I know how to do this from inside LabVIEW, but not from outside of LabVIEW.
Let me know if you have any questions or want to brainstorm on potentially how to solve (or who at NI could help solve) this issue.
-Jim