Generation of VS Code debug configuration #302

awillecke · 2023-07-26T10:40:38Z

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 · 2023-07-28T12:59:54Z

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 · 2023-07-28T09:46:27Z

cmake/launch.json.in

+				// OMNet++ interface can either be Qtenv or Cmdenv
+				// "-uQtenv",
+				"-uCmdenv"


Hi,
I was wondering, is not QTenv the default graphical environment and CMDenv is deprecated afaik.
I notice this on the website as well.
So should not it be the other way around, QTenv commented in and CMDenv commented out?

I don't think that Cmdenv is deprecated but Tkenv. Of course, Cmdenv is not a graphical environment at all but it is very useful for automated/headless simulation runs.

Then I mixed that up. Thank you for the clarification.

Enough7 · 2023-07-28T13:10:10Z

cmake/AddVSCode.cmake

+
+    # collect libraries for opp_run
+    set(opp_run_libraries "")
+    _get_opp_run_dependencies(${args_TARGET} opp_run_dependencies)


These are the OmnetC++ dependencies am I right?
Do they change frequently?

These are the libraries of Artery (e.g. libartery_core.so, libtraci.so, ...). These might change when building Artery with other flags (e.g. libartery_envmod.so when WITH_ENVMOD is ON) or when you extend Artery with custom functionalities. Basically, they could change with every (re)generation of the build system.

What happens if one includes all the libs all the time in the launch.json? Will this work?

Enough7 · 2023-07-28T13:13:58Z

cmake/AddVSCode.cmake

+    # backup existing launch.json
+    if(EXISTS ${args_FILE})
+        string(TIMESTAMP t)
+        file(COPY_FILE ${args_FILE} ${args_FILE}.${t})
+    endif()


If this does overwrite the file, then custom values get lost, am I right?

If a launch.json is found, it is moved to a new file and suffixed with the current time. This way, you would still have access to custom values, however, you would need to transfer them to newly written launch configuration again manually.

I think this is the biggest drawback especially for people with additional custom Configuration in their launch.json.

Enough7 · 2023-07-28T13:24:30Z

cmake/AddVSCode.cmake

@@ -0,0 +1,40 @@
+function(generate_vscode)


A doc-comment explaining the purpose of this function would be beneficial and appreciated 😃

Enough7 · 2023-07-28T13:27:52Z

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 · 2023-07-30T18:43:21Z

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 · 2023-07-31T09:45:10Z

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:

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).
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 opp_run) 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 · 2023-07-31T10:58:18Z

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?

Either deploys a new debug config or updates the previous one without removing other configs.

awillecke · 2023-08-02T09:07:39Z

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:

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

src/artery/CMakeLists.txt

cmake/AddVSCode.cmake

Generation of VS Code debug configuration

Adds generation of VS Code debug configuration to build process

13e139a

Enough7 reviewed Jul 28, 2023

View reviewed changes

Consider already present VS Code configs

cc0062d

Either deploys a new debug config or updates the previous one without removing other configs.

Enough7 approved these changes Aug 2, 2023

View reviewed changes

riebl requested changes Aug 5, 2023

View reviewed changes

src/artery/CMakeLists.txt Outdated Show resolved Hide resolved

cmake/AddVSCode.cmake Outdated Show resolved Hide resolved

Added option to generate VSCode debug conf

36b19fa

riebl merged commit 4885a0a into riebl:master Aug 9, 2023

AndK17 pushed a commit to CAVISE/artery that referenced this pull request Jan 4, 2025

Merge pull request riebl#302 from awillecke/vscode_debug

219f475

Generation of VS Code debug configuration

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Generation of VS Code debug configuration #302

Generation of VS Code debug configuration #302

awillecke commented Jul 26, 2023 •

edited

Loading

Enough7 commented Jul 28, 2023

Enough7 Jul 28, 2023

riebl Jul 30, 2023

Enough7 Jul 31, 2023

Enough7 Jul 28, 2023

awillecke Jul 31, 2023 •

edited

Loading

Enough7 Jul 31, 2023

Enough7 Jul 28, 2023

awillecke Jul 31, 2023

Enough7 Jul 31, 2023

Enough7 Jul 28, 2023

awillecke Jul 31, 2023

Enough7 commented Jul 28, 2023

riebl commented Jul 30, 2023

awillecke commented Jul 31, 2023

Enough7 commented Jul 31, 2023 •

edited

Loading

awillecke commented Aug 2, 2023

Generation of VS Code debug configuration #302

Generation of VS Code debug configuration #302

Conversation

awillecke commented Jul 26, 2023 • edited Loading

Enough7 commented Jul 28, 2023

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

awillecke Jul 31, 2023 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Enough7 commented Jul 28, 2023

riebl commented Jul 30, 2023

awillecke commented Jul 31, 2023

Enough7 commented Jul 31, 2023 • edited Loading

awillecke commented Aug 2, 2023

awillecke commented Jul 26, 2023 •

edited

Loading

awillecke Jul 31, 2023 •

edited

Loading

Enough7 commented Jul 31, 2023 •

edited

Loading