A standalone CMake Version - Builds on Windows

[HpLightcorner]

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

[riebl]

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.
Let's see if @thor is still interested in this topic. Ideally, I would love to see this repository at github.com/omnetpp/cmake :-)

[HpLightcorner]

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 get_ned_folders I get a recursion error. I could track the issue down to the following: CMake seems not to recognize the file-private function _get_ned_folders and instead calls get_ned_folders again. Do you have a similar experience?

Changing the name of the file-private function to, e.g. _get_ned_folders_ fixes the issue.

[riebl]

I have not experienced this error yet. Is there an CMake error message displayed or does the build process just fail then?
At the moment, I have CMake 3.20.1 installed on my main machine.

[HpLightcorner]

It fails in the following way (during configuration):

[cmake] CMake Error at cmake/omnet/GetNedFolders.cmake:31 (_get_ned_folders):
[cmake]   Maximum recursion depth of 1000 exceeded
[cmake] Call Stack (most recent call first):
[cmake]   cmake/omnet/GetNedFolders.cmake:31 (_get_ned_folders)

[riebl]

I have just checked it again with a fresh build directory: No issues on my machine.

[HpLightcorner]

Hmm, somehow weird. You are running Windows? Maybe there is a CMake Policy which has changed? Did you try to compile with cmake_minimum_required(VERSION 3.20) as this calls cmake_policy(VERSION 3.20) implicitly?

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.

[riebl]

I observe no difference with cmake_minimum_required(VERSION 3.20). However, I am using Linux.

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.

[HpLightcorner]

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?

[riebl]

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.
If you find Artery hard to build it would be valuable information, nevertheless.

[thor]

Hi @HpLightcorner and @riebl. 👋

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 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.

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.
Let's see if @thor is still interested in this topic. Ideally, I would love to see this repository at github.com/omnetpp/cmake :-)

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 opp_make after I came across the talk about using CMake for OMNeT++. I wanted something easily usable and decoupled. I think there's some value in having a helpful, standalone CMake setup, even if it's limited in functionality and unofficial. Preferably easy to use via subtree or as a submodule, of which I did the latter in my projects.

I think it'd be great if the CMake module could be hosted under @omnetpp, such as omnetpp/cmake. What do you think, @rhornig? Could that be an alternative? If not, I'd happily add you @riebl as a contributor to thor/omnetpp-cmake. Alternatively, we could transfer it if you'd prefer to maintain it under your account, seeing as it'd return to its source. Still, I'd appreciate contributor access in the event I get around to automating the testing. 😅

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?

[riebl]

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.

[HpLightcorner]

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 GenerateOppMessage and AddOppTarget - need some minor changes to work with version 6.0pre10 as the CLI of opp_msgc seems to have changed. Not that hard to implement - again another reason for a central home for at omnetpp/cmake.

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.

[thor]

So let's wait on the official omnetpp statement.

Here's hoping we'll catch @omnetpp's eyes!

By the way, @riebl what are the plans to update artery to 6.0? Because the CMake Files - namely GenerateOppMessage and AddOppTarget - need some minor changes to work with version 6.0pre10 as the CLI of opp_msgc seems to have changed. Not that hard to implement - again another reason for a central home for at omnetpp/cmake.

@HpLightcorner I believe the changes that came with opp_msgc were fixed in thor/omnetpp-cmake as I faintly remember having to fix that for my own project.

---

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.

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 README and remove any ambiguity.

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.

@riebl in the event we only hear radio silence, what would you prefer?

[HpLightcorner]

@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...

[riebl]

No, Artery does not need VoIPStream. ./inet_featuretool disable VoIPStream should do the trick. I will have to upgrade to INET 4.x as soon as I find some time to do so. I think the recent INET versions have no longer an inet_featuretool.

@riebl in the event we only hear radio silence, what would you prefer?

I have just pinged András by e-mail, hoping for some reply, be it negative or positive.

[HpLightcorner]

@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.

[riebl]

Those changes cause no issue with my setup. However, if you really need COMMAND_ECHO and ECHO_OUTPUT_VARIABLE the minimum supported CMake needs to get bumped up.

[HpLightcorner]

@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++...

[HpLightcorner]

@riebl - making serious progress with the Windows-Build.
However, I would like to set the CMake version to 3.20 - there are so features available - especially with path-handling (unix/windows-style) - that I really want to use.

Do you see any drawbacks?

[riebl]

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.

[HpLightcorner]

@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.

[riebl]

I have pushed my extern_cmake branch, which tracks and uses the omnetpp/cmake repository. You can simply checkout whatever branch you like/need in extern/omnetpp-cmake. I hesitate to track a feature branch, though.