Add an option to execute environment-setup script to add_opp_run

[HpLightcorner]

Hi,
When dealing with multiple OMNeT++ Versions, I normally avoid setting global environment variables. When using CMake, setting up various OMNeT++ Versions is supported by using CMake-Tools CMake-Kits. However, running a simulation directly from the IDE does not work as the DLLs are not found - because the paths are missing/not propagated.

It would be handy if I can add a setup script to commands like add_opp_run to, for example, modify the PATH.

Any thoughts on that?
I am implementing a prototype, setting up e.g. the PATH from within CMake for custom_target is not so straightforward, but I think I found a workaround.

[riebl]

I am only aware of the optional toolchain files of CMake, which are used for cross-compiling.
In my workflow, I source individual environment files for the respective OMNeT++ version. I am not sure if this works well with IDEs, though.

[HpLightcorner]

I will push a prototype that works great with VS-Code in a feature branch so that we can have a more focused discussion.

[HpLightcorner]

Hi @riebl and @thor
Would you mind having a look at my prototype? (there is a branch containing the feature)

Instead of adding an environment script (which could be another thing I would add later on), I decided on the main purpose of this request - the idea is to be able to debug simulations from within VS-Code and auto-generate the corresponding launch.json configuration for either GDB or the CodeLLDB extension to minimize configuration-effort.

I came up with a combination of a simple python script and the corresponding add_custom_command in CMake.
The script is based on this article - simply automating the process of generating command line etc.

It works with both debuggers (GDB and LLDB) on Windows, I am getting some strange results with CodeLLDB but I guess that this is just a simple setting I have overseen and I will open an issue at CodeLLDB to clarify my questions there.

CodeLLDB is way faster than GDB, but also GDB is working as expected.
The syntax to activate VS-Code support is as follows:

set(VSCODE_DEBUG_CONFIG CodeLLDB)
#
# Minimal working example
add_library(minimal SHARED 
    ./tests/example/txc.cpp
)

#
# Link Simulation-DLL
target_link_libraries(minimal PUBLIC 
    OmnetPP::sim
)

add_opp_run(minimal
    CONFIG ${CMAKE_CURRENT_SOURCE_DIR}/tests/example/omnetpp.ini 
    NED_FOLDERS ${CMAKE_CURRENT_SOURCE_DIR}/tests/example/
    DEPENDENCY minimal
    VSCODE
)

Resulting in the following configuration in the launch.json file:

{
    "name": "Launch minimal - CodeLLDB (OMNeT++)",
    "type": "lldb",
    "request": "launch",
     "program": "path/to/opp_run_dbg.exe",
     "args": [
            "-n",
            "path/to/tests/example/",
            "-l",
            "path/to/build/libminimal.dll",
            "path/to/example/omnetpp.ini"
    ],
    "stopOnEntry": false,
    "cwd": "path/to/project/root",
    "initCommands": [
         "command script import path/to/python/omnetpp/lldb/formatters/omnetpp.py"
     ]
}

Making VS-Code a more or less fully-featured IDE.

Limitations:

• The launch.json file must stick with strict JSON, so no comments and fault-tolerant interpretation

Debug-Limitations on Windows:

• When using CodeLLDB, symbols are interpreted correctly when hovering over the variable, but not shown in variable explorer on the left (i will open an issue at CodeLLDB) - at least this is true on Windows

EDIT: Linking discussion at CodeLLDB.

[riebl]

I think it should be TARGET ${target} POST_BUILD instead of TARGET ${name} POST_BUILD. A ${name} target does not necessarily exist, it is just the name of the run/debug targets. However, CMake complains that TARGET 'artery' was not created in this directory when I try it with Artery… I go with TARGET debug_${name} PRE_BUILD for now, but this does not automatically update my launch.json then.

Further changes:

• ${Python_EXECUTABLE} -> ${PYTHON_EXECUTABLE}
• add VERBATIM so opp_vscode_debug_config.py can parse all arguments as expected
• script does not play nice with empty launch.json (missing configurations)

In my opinion, the VSCODE option should not exist but add_opp_run should touch the launch.json file only if a particular (global) CMake variable or property is set accordingly. The arguments to add_opp_run should only vary according to project-specific peculiarities but not which IDE the user prefers.

Edit: Forgot to say that your prototype works nicely otherwise :-)
Edit2: Please note that python/omnetpp/lldb/formatters/omnetpp.py does not exist with OMNeT++ 5.6 yet.
Edit3: Also have to pass the working directory to opp_vscode_debug_config.py, it is not always the project root directory.

[HpLightcorner]

Hi @riebl,
Thanks for the feedback - hopefully you are enjoying this IDE feeling (outside Eclipse) with VS-Code and CMake like I do!

I was focusing on getting CodeLLDB debugging right (cause GDB is really slow on Windows). I had to develop some knowledge of how debugging is actually working to get to understand all settings, but now debugging with LLDB is also working like a charm. We have to compile with set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fuse-ld=lld -glldb -fstandalone-debug") and CFLAGS_DEBUG='-glldb -fstandalone-debug' in configure.user. especially -fstandalone-debug may slow down linking, however, using lld as the linker with this setting is still way faster than gdb/gcc. When doing a PR on this prototype we will have to make sure to document necessary flags if someone wants to use the debugging feature.

When everything is working the experience with VS-Code is really great. Using CodeLLDB extension to launch and debug gives true IDE feeling (however, CodeLLDB seems to be unstable sometimes - I updated the Q&A at CodeLLDB).

Totally agree with your suggestions. Are you willing to do a commit to your changes or shall I try to implement them?

[riebl]

I have pushed my changes to your feature branch. Right now, I am experimenting with how to trigger the launch.json generator best. Maybe adding a update_launch_json target solves the issues…

[riebl]

Why do you avoid creating a fresh launch.json if none exists @HpLightcorner? Is there any harmful case that I am not aware of?

[HpLightcorner]

I simply have not thought that through when creating the prototype, so I decided not to create the file if it does not exist. I will walk through your changes today and will also add my thoughts. I am working on my project in parallel, so I am testing the idea permanently :)

Btw. - I like the idea of having a update_launch_json target. Did you make some progress with that as well? (without looking into your commits...)

[riebl]

I have just pushed my changes towards a update_launch_json target to the update-launch-json feature branch.

[HpLightcorner]

Just one thing which is kinda annoying when working with launch.json: the VS-Code JSON interpreter is really forgiving a lot of mistakes (besides adding comments to the file). Are you aware of a JSON interpreter alternative similar to VS-Code (allowing comments and keeping them, being fault-tolerant)? Or is this even a good idea if we would add a non-native package in a python script? (how to manage install-steps - with CMake?)

[riebl]

No, I don't have a favourite JSON library for Python. However, I would rather avoid adding non-standard dependencies to our helper scripts. There be dragons…

[HpLightcorner]

I have the same view on additional non-standard dependencies, so I think letting the CMake target fail and print a meaningful error message such that the user can ensure that launch.json confirms with JSON standard is the way to go.