fix: devicelist.json baked in build-machine-relative configPath values, breaking config lookups after install - #85
Open
hangzqcom wants to merge 1 commit into
Open
Conversation
…s, breaking config lookups after install UpdateDeviceList.exe (the tool that regenerates configurations/devicelist.json from the .tcnf files in this repo) resolved each entry's configPath against tacConfigRoot() at generation time and wrote the resulting path into the JSON file. Since tacConfigRoot() depends on the machine/environment the tool happens to run on (e.g. a CI runner's checkout path or a developer's local repo layout), the resulting configPath ends up looking like "../../../../configurations/TAC_PSOC_82.tcnf" - a path that is only valid relative to wherever the tool was run from, not to an end user's installed package. At runtime, TACPlatformEntry::getConfiguration() opens this path exactly as stored, with no re-resolution against the actual install location. Any catalog entry with one of these baked-in relative paths therefore fails to load its .tcnf on every machine other than the one it happened to be generated on, even though the actual .tcnf file is correctly installed and present under the real config root - the failure is purely a bad stored path, not a missing file. 57 of 72 catalog entries in the committed devicelist.json were affected. Fixed by: - UpdateDeviceList.cpp: write only the bare filename (entryInfo.fileName()) instead of a resolved path, matching the existing runtime resolution intent - the config root should always be resolved on whatever machine is actually running the app, not baked in ahead of time. - PlatformConfiguration.cpp (TACPlatformEntry::getConfiguration()): when a stored path is a bare filename (no directory separators, not absolute), resolve it against tacConfigRoot() before attempting to open it. This is what makes the bare-filename form written above actually load correctly at runtime, on whatever machine/install location is running the app. - configurations/devicelist.json: regenerated with UpdateDeviceList.exe so every configPath is now a bare filename with zero relative or absolute path components. Verified locally: rebuilt the full solution cleanly with no new warnings or errors, regenerated devicelist.json and confirmed all 72 catalog entries now use bare filenames, and confirmed via a direct runtime check that a previously-failing platform (SHIKRA PSOC, platform_id 82) now loads its configuration successfully after a clean install. Signed-off-by: Hang Zhao (QCT) <hangz@qti.qualcomm.com>
hangzqcom
force-pushed
the
fix/devicelist-configpath-bare-filename
branch
from
September 9, 2026 22:32
8236743 to
f34fc38
Compare
There was a problem hiding this comment.
Hello hangzqcom , Device Catalog configuration table provides a visual clue to the end user on the location of configuration on their system which helps them review the file in case they want to modify and prepare one for a similar platform. We want to keep the functionality the same way as we've been using until now.
We want to stick to the original workflow. Configurations can be generated on a per use-case basis in the CI, please use the same for your workflow.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
configurations/devicelist.jsonstores aconfigPathfor each catalog entry, pointing at its.tcnfconfiguration file.UpdateDeviceList.exe, the tool that regenerates this file, was writing a path resolved againsttacConfigRoot()at generation time (e.g.../../../../configurations/TAC_PSOC_82.tcnf). That path is only valid on the machine/checkout layout the tool happened to run on — it has no meaning on an end user's installed copy of the app.At runtime,
TACPlatformEntry::getConfiguration()opens whatever string is stored inconfigPathexactly as-is, with no re-resolution against the actual install location. So any catalog entry with one of these baked-in relative paths fails to load its.tcnfon every machine other than the one it was generated on — even though the.tcnffile itself is correctly installed and present. 57 of the 72 entries in the currently committeddevicelist.jsonare affected this way.Symptom on an installed package:
Fix
UpdateDeviceList.cpp: write only the bare filename (entryInfo.fileName()) intoconfigPathinstead of a machine-resolved path. Path resolution should always happen at runtime, against whatevertacConfigRoot()actually is on the machine running the app — not be baked in ahead of time.PlatformConfiguration.cpp(TACPlatformEntry::getConfiguration()): when a storedconfigPathis a bare filename (no path separators, not an absolute path), resolve it againsttacConfigRoot()before opening it. This is what makes the bare-filename form above actually work correctly at runtime on any install location.configurations/devicelist.json: regenerated with the fixedUpdateDeviceList.exeso everyconfigPathis now a bare filename with no relative or absolute path components.Testing
devicelist.jsonand confirmed all 72 catalog entries now use bare filenames (previously 57/72 had relative paths).SHIKRA PSOC, platform_id 82) now loads its configuration successfully viaTACPlatformEntry::getConfiguration()after a clean install, where it previously failed.