support for native_sim target on Zephyr RTOS

[TomzBench]

Hello,

It would be very interesting to support the native_sim target for the zephyr platform. This is very useful for testing and development. Zephyr provides its own abstraction layer, allows access to emulated gpio, etc. Essentially you would be able to run an emulated server, and readback emulated gpio state using the emulated drivers

When I try and build for the native_sim target, i believe mongoose is trying to link with MG_ARCH_UNIX. Even though im doing my best to try and get it to be MG_ARCH_ZEPHYR. Likely something going on with #ifdef __unix__ 's in there favoring the host tooling instead of using the ZEPHYR arch and relying on the zephyr abstractions.

[scaprile]

Instead of guessing, let's try doing the right thing.
Exactly what do you build, how do you build it, what fails, where, etc.
I personally don't care about having 3 abstraction layers on top of a gpio, and Mongoose certainly does not gpios, but we'll provide as smoothest as possible a building experience for whatever combination we can support with a reasonable effort (or the specific request of a paying customer).

[TomzBench]

i got it to build and link using

zephyr_compile_options(-include ${ZEPHYR_BASE}/arch/posix/include/undef_system_defines.h)

This is apparently a hack that the zephyr tooling is doing to strip away any HOST compiler definitions which forces the compiler to rely on zephyr's system includes. So by copying this strategy when building mongoose seems ok so far

Ill report back any other tweaks i need along the way!

As far as paying customers go, we're evaluating! ...the stock zephyr HTTP server is not very good. (See my rant here)

[scaprile]

Well, that is not the way to build a Mongoose project. I don't even know what that is. Our projects have a Makefie that calls west build and gives a board definition using -b. Any other configuration goes into prj.conf

From the top of my head, we don't any random #ifdef for Unix stuff, we define an MG_ARCH and any additional #ifdef is done inside that MG_ARCH. That means, if you build for MG_ARCH_ZEPHYR, you build for Zephyr and there shouldn't be any Unix-related detours in our code.
That is done inside src/mongoose_config.h:

#define MG_ARCH MG_ARCH_ZEPHYR

That file is pulled when an already-known MG_ARCH has not been detected. Under some circumstances, if your particular environment is suggesting a Unix environment, it is possible that MG_ARCH_UNIX is being picked up automagically and that file not being pulled. You are not building for a standard known environment, but a custom one, and we got you covered with MG_ARCH_CUSTOM:

• In such a case you need to pass MG_ARCH=MG_ARCH_CUSTOM to your compiler, e.g.: -D MG_ARCH=MG_ARCH_CUSTOM for gcc/clang, unfortunately I don't have the slightest idea how to tell west to do that.
• Once our code sees it is being compiled for MG_ARCH_CUSTOM, it will pull mongoose_config.h and there you will define MG_ARCH=MG_ARCH_ZEPHYR as above.

Well, your comparison is not fair, everything pales against Mongoose 😉 Our strength is ease of use, if you find something easier, we'll do our best to beat it. BTW, have you checked the Wizard ?

[TomzBench]

The MG_ARCH MG_ARCH_ZEPHYR is picked up when building for most boards I tried. However, when i build the native_sim/native/64 target, it seems like it is detecting a unix build, and so it no longer picks up the mongoose_config.h. By including zephyrs undef_system_defines hack, then it appears whatever mongoose is doing to detect the compiler falls back to mongoose_custom.h as expected, and then everything hums along like you would want.

I would prefer a "right" solution, however - it would involve messing with mongoose.h. so the solution here is less invasive. I posit it is therefore the "right" solution for me :)

I have not explored the Wizard. I typically am not a big fan of no code solutions. I like to write code and find WYSIWYG always annoying! Tho I understand some people like it. GUI infrastructure is normally a sign of a great project though - as its certainly an over the top feature.. so long as its not a default IMO.

[scaprile]

The wizard is mostly intended for people not wanting to invest effort on learning to write GUI code.

You don't need to mess with mongoose.h, you just need to tell west or whatever you use to build, to pass -DMG_ARCH=MG_ARCH_CUSTOM to the compiler. That would be IMO the proper way to build in this case. Hiding stuff the Zephyr way may provide the same. As long as you know what you're doing and are able to tell and control when you are building for a simulator and when for an actual board, that's fine. In our case, we used to use a fake Intel board that runs over qemu, by using an overlay file for its Eth controller (you may find traces of it in some projects) and using the proper -b to tell Zephyr to build for it.

I'm not versed into west and we're not fond of cmake either, on a short search maybe you can try this:
west build -b <board> <application_path> -- -DCMAKE_C_FLAGS="MG_ARCH=MG_ARCH_CUSTOM"

OTOH, however, building this way may tell Mongoose the proper environment but maybe some part in the rest of your code gets fooled the same way Mongoose was fooled before, so probably just using the Zephyr hack is best.

We might take a look at this later, that Intel board has been enough for us for a long time.

[TomzBench]

I took another try to do it the right way and managed to get it to compile with native_sim/native/64, however I needed to add

#if CONFIG_BOARD_NATIVE_SIM
#include <zephyr/posix/signal.h>
#endif

To the mongoose.h MG_ARCH_ZEPHYR section...

I could do a PR maybe if testing goes ok if interested