-
Notifications
You must be signed in to change notification settings - Fork 4
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an option to execute environment-setup script to add_opp_run #7
Comments
I am only aware of the optional toolchain files of CMake, which are used for cross-compiling. |
I will push a prototype that works great with VS-Code in a feature branch so that we can have a more focused discussion. |
Hi @riebl and @thor 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 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. 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:
Making VS-Code a more or less fully-featured IDE. Limitations:
Debug-Limitations on Windows:
EDIT: Linking discussion at CodeLLDB. |
I think it should be Further changes:
In my opinion, the Edit: Forgot to say that your prototype works nicely otherwise :-) |
Hi @riebl, 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 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? |
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… |
Why do you avoid creating a fresh launch.json if none exists @HpLightcorner? Is there any harmful case that I am not aware of? |
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 |
I have just pushed my changes towards a |
Just one thing which is kinda annoying when working with |
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… |
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 |
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 thePATH
.Any thoughts on that?
I am implementing a prototype, setting up e.g. the
PATH
from within CMake forcustom_target
is not so straightforward, but I think I found a workaround.The text was updated successfully, but these errors were encountered: