Fix compiling native when main project is cross-compiling

[noahknegt]

I am using this framework for unit testing and with that using meson. With meson i use this framework as a submodule and with the main meson project being cross-compiled it tried to cross-compile the framework as well, although the unittesting is done on the host machine. To fix this I added the native parameter to the the definition of the static library, so that that when used as a subproject in a crosscompiled project it will be used as a native instead of a cross project.

The submodule of Unity was updated to also include the changes of the native compilation there.

[Letme]

Maybe I do not understand but you said when you cross compile for production, then meson also tries to compile cmock and unity (which it should not). Isn't there a better configuration for this? Or is that you want to end up with cross compiled sources while framework would be for host-which kinda also does not make sense since objects need to link and run together, otherwise there is no use compiling...

[noahknegt]

As it stands now whenever meson is used with a cross-file, so prepared for cross compilation and cmock and in extension also unity are build with the cross-compiler. So in my example I'm using an STM32 cross-target and without these native parts in the meson files, meson configures cmock and unity to be cross-compiled as well, so for the STM32, but unit testing is done on the hostmachine aka native so in order to let cmock and unity be compiled for the hostmachine to be linked with the unittest that are also native the native: true had to be added, just like the PR for unity a couple of weeks back. I hope I explained it well right now.

[Letme]

OK, so this is the flag which allows you to compile "natively" as well as cross compile when you globally set it to false. Problem will be if you want to run unittests on simulator on host machine. So how would you solve that?

[noahknegt]

Imo if you'd like to run them in a simulated env then for those systems it should be plausible to also compile in the simulated env thus that env will be native, otherwise i see no use for running unit tests in a simulated env if you can also mock IO for example. Hope i made it clear enough otherwise lmk.

[Letme]

When you use simulator you cross-compile mocks, unit tests and everything else for target and then execute on host via the simulator (or on target via debugger). That is not production elf (in your stm32 case) but it is unit test elf. It would also run directly on your STM processor and send results through debugger. So for that use case you will cross-compile everything and mock IOs and other component APIs, because you want deterministic tests. Use case of this is to eliminate compiler/architecture specifics. For example your CPU is 64bit so some maths (truncations without strong typing) will be very different to 32bit STM, or even 8bit Atmega. Not to mention compiler does its magic, so you also want to test out that part.

Normal use case is that unit tests (and other code) are compiled for native and executed, while release build (production elf) is cross compiled for target. However, CMock and unity have almost no dependencies on this use case, in fact you can compile, link them and execute them (target, simulator, fpga) even on a proprietary 16bit CPU architecture I am currently working with (and no, you cant compile it natively on a 2kb RAM and 12kb ROM with 24kb flash unless you want to die of old age).

[noahknegt]

Alright then I shall keep this feature in my own fork then, as i don't have the time nor the knowledge right now to discuss about this any further. But I'd like to mention to you that the Unity framework itself has added this new "feature" so in the future when you want to update the unity git submodule you'll either have to change it or remove it again from the unity framework. Thanks for your insights and time into this.

[mvandervoord]

It's not sounding like this has more potential for problems than it fixes. Perhaps this might require revisiting the same feature on Unity?