st-flash and other utilities search for chip files in the wrong directory

[slyshykO]

• OS: Linux on ARM
• version 1.7.0-105-gdb8f789 (lastest develop)
• st-info, st-flash, st-trace, st-util

make install copied chip's files to /usr/local/etc/stlink/chips but st-* utils search them in /etc/stlink/chips

[Nightwalker-87]

Another classical example for unfinished attempts... :-/
Regression from #1129.

[slyshykO]

Another classical example for unfinished attempts... :-/

Don't be discouraged. This is a typical process in software development :)

[Nightwalker-87]

Yes, but it should appear on private/personal branches with intermediate working (sub)sets to be proposed for a merge each and not within endlessly reworked PRs that then appear to stall. That's the point and this is actually causing such problems. PRs are not spaces for development, but for final review and last additional changes.

I just find this regression deriving from such a background - that's why.

[Nightwalker-87]

The hardcoded path /etc/stlink/chips is definitely wrong - we shall never use hardcoded paths without the ability to define a variable cmake prefix.

Thus changing install(FILES ${CHIP_FILES} DESTINATION ${CMAKE_ETC_CHIPS_DIR})

into install(FILES ${CHIP_FILES} DESTINATION ${CMAKE_INSTALL_PREFIX}/${CMAKE_ETC_CHIPS_DIR})

within /CMakeLists.txt should actually fix this. Please let me know about the result.
I'd provide a fix then with some other minor clean-up as well.

[Nightwalker-87]

Another leftover is the old chip configuration in /src/stlink-lib/chipid.c - it should be removed after a comparison of the respective MCU configuration and no longer remain as a duplicate. Otherwise it will simply stay there forever... I still don't understand why this has not taken place during the move to the file-based configuration - there is no rational explanation for this.