Linux support and more.

[poshcoe]

Hi, first of all - love the project.

Over the last few days I've been working on some improvements to the scripts, largely to do with cross-platform support. Here's the breakdown:

• Now works on Linux (Ubuntu 18.10) properly
• Simplified user-required configuration by:
  • Detecting default paths (currently Linux only)
  • Allowing relative OpenOCD configurations (absolute paths found internally)
  • Improving feedback to user
• Re-worked the structure of updatePaths.py
• Detects incompatible python versions
• Generalised some functions in utilities.py

[schperplata]

@poshcoe I've had a couple of issues with your latest commit. At a first glance it looked fine to me, but once I started working, there were issues right away. Mostly:

• Cached target '*.svd' file
• Unparsing openocd configuration string (possible paths with spaces, as default on windows)
• Sometimes wrong imported paths from toolsPaths.json
• Minor stuff due variables renaming, ...

Anyway, I have fixed some stuff and rewrite some stuf to the old concept. Here is what&why:

• Target '*.svd' file is now NOT cached in 'toolsPaths.json' Can't be, user can use different STM32 devices. This also means that SVD folder path is not used anywhere, so it was deleted. Your trick with listing files is now gone :(, but maybe a better search algorithm could be implemented if this files are hard to find. I didn't have problems so far, since I kept them in a common GNU ... folder.
• Cached OpenOCD interface path (stlink.cfg) Currently only this interface is supported and can be cached. This is also the reason why user is specifically asked to pass path to OpenOCD interface file, separately from other OpenOCD configuration files.
• OpenOCD configuration files still support multiple files, but are passed a little different: can be enquoted in "/' (to support spaces) and separated by comma, not spaces. I've left your absolute/relative path support, seems like a good idea.

For (hopefully) further participation:

• Try not to change variable names that are part of any '*.json' file, so backward compatibility is not broken. For example, renaming openOCDPathto openOcdPath.
• Feel free to comment/recommend a better solution before you make yourself a lot of work with coding. I think that together we can figure out a better/best solution if we discuss "major" changes in advance.
• Let me know if you experience any issues with latest commit on Linux.

Thank you!

[poshcoe]

Hi, I've made some notes about your changes.

• I should have pointed out that the old toolsPath.json would need to be re-generated. For backwards compatibility in the future perhaps some function could be added to ignore variables in the file that are no longer applicable to this version, remove them, and simply add the missing variables to the file (after getting input for the new variables from the user).
• My mistake in not removing the SVD file from toolsPath.json, for now it's fine to remove the SVD path support. My goal was that the SVD path would be cached across projects such that in a new project the SVD path would be detected and the user would ls and choose their SVD file - Though I understand this wasn't working just yet.
• For OpenOCD configurations, I'm not sure why you would separately cache the interface path and hard-code it. I don't think that we should be deciding which configuration scripts the user decides on for OpenOCD, as custom configuration scripts are common. It's true that the IDE is limited to STM32s, but I cant see any reason that limits us to using the stlink programmer. OpenOCD is powerful as a single tool for using multiple interfaces, we should take advantage of that! As for the spaces in configuration file paths, I thought I already had that working if you surrounded the path with double quotes - regardless I agree with the decision to separate via comma and strip leftover spaces.

I agree about better communication before major changes, but maybe the approach from my end would be improved by breaking this pull request up into smaller changes to focus on.

[schperplata]

• 1 ... some function could be added to ignore variables in the file that are no longer applicable to this version ... If different version of ideScripts are changing 'toolsPaths.json/buildData.json' on each run, user would always have to update paths while changing from one project to another, if he doesn't (or for some reason doesn't want to) update ideScript folder and just wish to continue with work. I think that if changes to variables/file syntax is changed (should be avoided), better approach would be to introduce versioning - data for ideScripts v1 would have its own container, v2 its own, ... OR, just create new variable, but this could clutter code/file as ideScripts evolves.

• 2 ... Though I understand this wasn't working just yet. ... This could totaly work if all '.svd' files would be in one folder. But, as the simplest way for user is to just download package from Keil and extract it in common folder, path to common SVD folder can't be inside one extracted package, since it might be different for other project. Anyway, the alternative which I didn't think of yesterday :(, would be to cache path were all extracted SVD packages are placed and some algorithm would than search and list all '.svd' files. It is still possible to implement it, but I would wait a little bit, since I don't find this an issue. Another idea, maybe when searching for config files (OpenOCD/SVD), default paths could be recommended - user can than quickly copy&paste&navigate to that folder and get exact path.

• 3 OpenOCD is powerful as a single tool for using multiple interfaces, we should take advantage of that! Totaly agree with that. The problem I see is that different interfaces needs different VS Code launch/tasks/workspace configurations. It is not enough to just pass configuration files. As currently only stlink is implemented, I think it is fine to cache it. Anyway, If there will be more users that would need other interface support, we can still implement it later.

• 4 ... by breaking this pull request up into smaller changes to focus on... Oh, that is right. I will do my best.