-
Notifications
You must be signed in to change notification settings - Fork 130
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
A standalone CMake Version - Builds on Windows #184
Comments
Hi @HpLightcorner, Until your post, I have not been aware of the thor/omnetpp-cmake repository at all. I agree that having multiple copies of almost the same "thing" is an unfortunate situation. Right now, I have no answer on how to proceed best; however, adding the OMNeT++/CMake glue via a submodule is definitely a viable option for me. |
I just came across another issue - I will simply append this as it is loosely coupled to CMake. I am using CMake version 3.20. When calling Changing the name of the file-private function to, e.g. |
I have not experienced this error yet. Is there an CMake error message displayed or does the build process just fail then? |
It fails in the following way (during configuration):
|
I have just checked it again with a fresh build directory: No issues on my machine. |
Hmm, somehow weird. You are running Windows? Maybe there is a CMake Policy which has changed? Did you try to compile with At least I managed to set up a complete build environment based on the latest CMake files in artery repository, only those mentioned minor changes where necessary. Debugging with VS-Code and the CMake extension would somehow be nice, not sure if this is already possible. |
I observe no difference with Since I had never the patience to get Artery running on Windows, I would appreciate a pull request with the necessary changes to get Artery running on Windows. If you can provide some hints on how to install Artery on Windows, I would be more than happy to include them in the documentation. |
To be honest, I am currently focusing on using the CMake files only to set up my simulation (I want to simulate parts of my microcontroller firmware)... I am working on a simulation for Time Sensitive Networking for my PhD thesis. But let me have a look into building artery on Windows - maybe I have already done most of the hard work? Especially if we decide to make the CMake files standalone it should work out of the box on both platforms. Do you have any further Linux/platform specific dependencies I should be aware of before giving it a try? |
Ah, I got you wrong then: I thought you tried to get Artery running on Windows. Anyhow, there are no Linux-only dependencies I am aware of. I am just too lazy to compile all the libraries on Windows, especially as I am not developing with Windows at all. |
Hi @HpLightcorner and @riebl. 👋
I certainly hope you submit it as a PR somewhere, be it here or in thor/omnetpp-cmake. I'm sure you won't be the last person to use it on Windows.
While I have no active OMNeT++-related projects at the moment, I'm still maintaining a couple of OMNeT++ related things (such s the AUR packages for the stable and the preview version), and thus I'm still interested in giving a hand where helpful. My goal with the repository was to get away from I think it'd be great if the CMake module could be hosted under @omnetpp, such as As long as those interested in using it will be able to do so and contribute to any (appropriate) changes, I'd be glad to see such a small derivative module built on the back of @riebl's work continue to be used by users outside of Artery too. 👍 PS: Either way, this seems like a great time to confirm from you @riebl that the license is the same as for the rest of the project. Is that the case? |
Thanks for your reply @thor! If not explicitly noted, e.g. as for the bundled SUMO source code, Artery is licensed under GPL. I will add a clarification to the readme and/or a license file in the root directory. I am hoping for an "official home" at omnetpp/cmake as it causes less confusion about which repository is only a fork and which one is the maintained upstream repository. So if the OMNeT++ team has no concerns, I prefer omnetpp-cmake to become a semi-official git repository. |
So let's wait on the official omnetpp statement. Just to add some information to the discussion: As promised I am currently trying to build artery on Windows - and so far a lot seems to work fine with some minor changes in the CMake files (all documented now in this discussion) - I started with building INET. By the way, @riebl what are the plans to update artery to 6.0? Because the CMake Files - namely I am currently rebuilding a fresh omnetpp-5.6.2 version and will then proceed with building artery - I will need INET anyway for my project and hence I can copy the INET-CMake files. |
Here's hoping we'll catch @omnetpp's eyes!
@HpLightcorner I believe the changes that came with
No worries, thanks to you too! Your CMake module, with some fixing for OMNeT++, saved me for sure. Thanks for the confirmation; I'll update the
@riebl in the event we only hear radio silence, what would you prefer? |
See riebl/artery#184 (comment). It's all GPL, like we assumed. Phew.
@riebl - I came across an error when building artery on windows with INET VoIPStream - it seems that ffmpeg is not installed in the MSYS environment of omnet++. Is VoIPStream needed by artery? I will also have to find out how to use inet_featuretool to disable features if not needed... |
No, Artery does not need VoIPStream.
I have just pinged András by e-mail, hoping for some reply, be it negative or positive. |
@riebl - can you do me a favour? I found the issue with VoIPStream - on windows the Python-Featuretool cannot directly be executed. To get the Makemake flags I need to change the command by calling the script using the Interpreter: find_package(Python COMPONENTS Interpreter)
execute_process(COMMAND ${Python_EXECUTABLE} ${OMNETPP_FEATURETOOL} options -l -f
WORKING_DIRECTORY ${INET_DIR}
OUTPUT_VARIABLE INET_OPP_MAKEMAKE
COMMAND_ECHO STDOUT
ECHO_OUTPUT_VARIABLE
) Can you check if this breaks Linux compatibility? I expect this change to be cross-platform. |
Those changes cause no issue with my setup. However, if you really need |
@riebl that was just for debugging... I mean, we will need to discuss this in a broader way anyway... There seem to be some breaks between the CLI of version 5 and 6 of omnet++... |
@riebl - making serious progress with the Windows-Build. Do you see any drawbacks? |
I try to remain backwards-compatible with the current Debian stable version as much as possible. Debian Buster ships with CMake 3.13 and thus I don't want to enforce 3.20 at the moment. I would be fine with requiring 3.20 for Windows builds, however. |
@riebl - now that we have the official CMake proceedings, do you mind creating a branch with the new CMake repository in place? And select the Windows Feature Branch? (once everything is working on Linux and OMNeT++ 5.x) I will then resume building on windows. |
I have pushed my |
Hi,
I am currently investigating the excellent work done by this repository and its contributors using CMake with omnet++. It allows a more modular approach to omnet++ builds and hopefully this is also an option for my current project. There is actually a standalone version of the CMake files available, however, it seems that commits have been done to artery and omnetpp-cmake since this "fork" and @riebl is also a contributor of omnetpp-cmake.
To be honest, it would be a charm if artery would add the CMake files and their dependencies (scripts?) as a GIT Submodule so that others can use the approach in their projects and make maintenance a lot easier.
For example, I am forced to use Windows, and my first tests have shown that the CMake files are missing just two lines of code to work with the simple Omnet++ example. Adding
IMPORTED_IMPLIB_<CONFIG>
and using the correct CMake-Kit allows to directly build and run a simulation from, e.g. VS-Code.I am currently not sure how to proceed - shall I start contributing to omnetpp-cmake? Shall I make another "fork" of the CMake files just for my use case? (By the way, I opened an issue there as well).
I guess artery will proceed with supporting version 6 of omnet++, and if changes are necessary to the build system other users can also contribute and take advantage.
From my perspective, a submodule with a single point of maintenance would be the best option.
Looking forward to hear from you and thanks for your effort
The text was updated successfully, but these errors were encountered: