Skip to content

Misssing <resource> symbolic link handling in "TranslateLVSymbolicTokenToPath.vim"#64

Open
AndreaV-Lsi wants to merge 2 commits intojovianarts:mainfrom
AndreaV-Lsi:main
Open

Misssing <resource> symbolic link handling in "TranslateLVSymbolicTokenToPath.vim"#64
AndreaV-Lsi wants to merge 2 commits intojovianarts:mainfrom
AndreaV-Lsi:main

Conversation

@AndreaV-Lsi
Copy link
Copy Markdown

@AndreaV-Lsi AndreaV-Lsi commented Mar 27, 2026

What does this Pull Request accomplish?

This PR Closes #63 . "TranslateLVSymbolicTokenToPath.vim" doesn't handle the <resource> symbolic path. This means that LabVIEW Solution Builder doesn't detect dependencies on libraries in <resource>. After the fix, this is the result of executing LabVIEW Solution Builder to build the example project attached to the bug report.

Bug Fix

High-level Checklist (if any apply):

  • New feature
  • Fixed bugs
  • Tech debt (typo, added comments, small logic change, improved code performance, etc.)

"TranslateLVSymbolicTokenToPath.vim" was edited by adding the "resource" case to the case structure by duplicating the "userlib" case and suitably editing it.

Why should this Pull Request be merged?

This bug might affect projects that need to build PPLs out of libraries residing in the <resource> folder

What testing has been done?

  • Ran /src/_tests/RunTheTests.vi and all tests passed

All the test passing before the bugfix pass after the bugfix.

What Release Build Should This Go In?

  • It can wait until the next release and get bundled with other changes.
  • It's urgent, I'm requesting a new release build ASAP.

…with a change history of the Top-level Library

This addresses Bug jovianarts#61

When we edit a PPL build specification and we change the "Top-level library" from say "Library A.lvlib" to "Library B.lvlib", and we don't assign "Library A.lvlib" to "Always Included", traces of  "Library A.lvlib" are left in the project XML file build specification filed in the "Source" array. This results in the fact that the

Source[%d].sourceInclusion .neq. "Exclude"

 will yield TRUE while the"Library A.lvlib"  is not included in the build specification. For this reason, we OR compound the .neq. check with an "Empty String/Path?" check. If we don't do this, we end up with spurious inclusions that can cause bogus circular dependencies

Source code was edited in LabVIEW 2019 SP1. Failing Unit Tests were failing before the fix
"TranslateLVSymbolicTokenToPath.vim" doesn't handle the <resource> symbolic path. This means that LabVIEW Solution Builder doesn't detect dependencies on libraries in <resource>.

Handling of <resource> was added to "TranslateLVSymbolicTokenToPath.vim"

This Closes jovianarts#63
@AndreaV-Lsi AndreaV-Lsi requested a review from jovianarts as a code owner March 27, 2026 22:05
@AndreaV-Lsi AndreaV-Lsi changed the title Misssing \<resource\> symbolic link handling in "TranslateLVSymbolicTokenToPath.vim" Misssing <resource> symbolic link handling in "TranslateLVSymbolicTokenToPath.vim" Mar 27, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

bug: "AF Debug.lvlib" and "Actor Framework.lvlib" circular dependency not detected

1 participant