Generation of VS Code debug configuration

[awillecke]

The process of adding Artery to VS Code for debugging can be quite error-prone (see #215). This PR adds the generation of a generic launch configuration for VS Code to the build process. It is only generated when building Artery in debug mode and will back up existing launch configurations.

One further consideration would be to build this config only on demand, so it does not clutter the working directory. What do you think?

[Enough7]

One further consideration would be to build this config only on demand, so it does not clutter the working directory. What do you think?

I would just commit examples/templates of these .vscode files, eg. suffixed with .example like launch.json.example. So its possible to copy and paste them without the suffix. Given that we add the folder .vscode to .gitignore Git's working tree does not get cluttered. In another team we usually handled .env-Files that way.

In contrast to your proposal this way is more simple and stupid, which is beneficial regarding maintenance, robustness and effectiveness. The CMake Build configuration is in my opinion large enough. This makes it hard for newcomer developers to stay on top of things. What if someone breaks this by accident. Project developers will never notice this, because they got they .vscode files already. New developers get confused and in the end they are frustrated because there is no .vscode config.

[Enough7]

I think what this needs is some kind of indirection. Maybe it is possible to write the dependencies and so on to an environment file and include it in the .vscode/launch.json 🤔

[riebl]

I welcome any effort to make our lives easier. Just as @Enough7 I am sceptical if overwriting the launch.json is the way to go, though. AFAIK, VSCode support for customization regarding launch.json is quite limited. I am not aware of any "include" mechanism, for example. An alternative approach might be an "Artery launcher executable" (replacing the plain opp_run) which could evaluate various environment variables and alike. Just brainstorming here.

[awillecke]

Thanks for your feedback and comments.

I agree that overwriting the launch.json is not very nice (although the existing one is backed up) and might lead to confusion.

I think what this needs is some kind of indirection. Maybe it is possible to write the dependencies and so on to an environment file and include it in the .vscode/launch.json thinking

An environment file is indeed quite nice and very useful to have. I could imagine a file, containing the OMNETPP_ROOT, the NED folders and all necessary libraries. This file could be used to supplement the launch.json for the specific environment.

However, I encountered several issues after experimenting with it:

1. Variables specified in the envFile cannot be used to change the programm path, pointing to opp_run_dbg. So is necessary to either depend on the OMNeT++ being in the PATH or setting the path to the OMNETPP_HOME as specified for the building process (which is similar to the handling of run_artery.sh).
2. AFAIK, an individual key-value pair is required in args for each library to be loaded. It seems to be quite difficult to generate these from a single environment variable string using Code only. Furthermore, the number of libraries depends on the CMake build configuration, making it more complicated.

An alternative approach might be an "Artery launcher executable" (replacing the plain _opprun) which could evaluate various environment variables and alike. Just brainstorming here.

I think this approach should work to circumvent the current limitations of VS Code regarding configuration. However, I personally do not like having another runner, if it can be avoided. But if you are more in favor of this approach, I would also be fine going this route :)

One further approach could be to utilize CMakes JSON support to modify the launch.json that may exist. CMake could find the previously generated launch configuration and, if required, modify the build depended JSON keys (program, NED folders and libraries) accordingly.

[Enough7]

I am not aware of any "include" mechanism, for example.

Maybe opp_run_dbg has flag which allows to read the libs from a file or maybe there is a command which can be used to generate a tmp-launch.json? Probably someone before us had this problem too because this is a quite common problem if you see it in a tech-agnostic way. I guess, there might be a solution to it somewhere.

Edit: Brainstorming

• Maybe develop a Artery-Extension and play with the VSCode API
• Variable Substitution can be used in VSCode
  • Variables in VS Code settings, how? - Stack Overflow
• Maybe it is possible to use more than one launch.json?

[awillecke]

Thanks for your thoughts on this. Unfortunately, all libraries need to be specified individually using the -l flag.

• In my opinion, an extension would be too extensive. However, it would open up new opportunities for further features.
• The issue with substitution is that only CMake knows exactly how many libraries and, thus, key-value attributes there need to be given as arguments to gdb
• AFAIK, only one launch.json is possible, which holds multiple configurations.

Based on your feedback, I adjusted the current approach to the following:

1. When building as Debug, generate a default configuration to build/launch.json.default from the template
2. Check if .vscode/launch.json exists
3. If present, add/overwrite just the default configuration