Changes for Windows build of updated Emulator

[SergeAgeyev]

Added missing functions bodies (random, randomSeed)
Added windows compile note (comment)
Added ability to manually run workflows

[SergeAgeyev]

Latest update and sync of Arduino api folder are cool things, but some parts need some polishing at least on Windows.
Also, Windows build becomes tricky a bit (because of string.h / String.h problem on case insensitive files system).
Windows build solution exists, but now less obvious, so I documented in comment in Arduino.cpp

[pschatzmann]

I am wondering: is the cmake build failing on Windows because of the string caps problem ?
The official answer from Arduino is to use include "api/String.h" instead of include "String.h", but I see that they did not follow this rule in their code...

If this is still causing issues, I will consider to move back to WString.h

[SergeAgeyev]

Solution with #include "api/String.h" would work only if api\ will not be part of includePath, so all includes of any files from api should be changed.

In current situation includePath order does the trick on Windows, so compile is possible.
Solution with WString.h has disadvantage, as required to change ArduinoAPI reference core implementation.
Probably replacement ArduinoAPI core as submodule in future is much more important :)

I think let merge it as it is with String.h as Windows build still a non-priority and solution for Windows exists.
We use Windows for unit testing and intelisense+copilot.

[pschatzmann]

I was doing some tests on OS/X and it was failing there as well.
So I finally decided to stick with the legacy WString.h to avoid any issues on all platforms that are case insensitive.

Can you double check with the actual state and open a new pull request for things which are still not working in Windows ?

[SergeAgeyev]

While this solution with WString.h would work (as it was worked) and I will check it, it seems authors of arduino core api had another interesting ideas.

They prefer not to add /api/ into include path, so all stuff from there should be included as <api/something.h> including api/String.h. if we reference all standard stuff this way in ArduinoCore-Linux, it may work without trick with WString.h, so I am checking this now.

[pschatzmann]

I was hoping that Arduino provides an api implementation that compiles as-is w/o issues on all platforms.
Unfortuantely this is not the case.

[SergeAgeyev]

Obvious solution is to rename String.h to AString.h or ArduinoString.h in source ArduinoCore-API implementation, but seems noone take care about it. At the moment on latest ArduinoCore-API everything migrated to <api/*.h> (that is api is not in path).

I did migration to api/*.h includes in ArduinoCore-Linux folder and its compiles now.
So looks we may return back to idea of having ArduinoCore-API as submodule.
I will do some more checks and soon push it in https://github.com/openlab-vn-ua/Arduino-Emulator

As for me, goal to have ArduinoCore-API as submodule is very good goal.
Your port to RPi opens whole new bunch of possibilities and I hope it would be part of Arduino platform someday.
It will bring back need of non WString.h solution, so let try to find it.

[pschatzmann]

I pretty much gave up an the idea of a submodule.
I also needed to adapt some compile options in test/CMakeLists.txt to make it compile with OS/X

[SergeAgeyev]

I managed to compile it with original code from ArduinoCore-API under Windows and it works!
Practically solution is absolutely simple: just exclude ArduinoCore-API/api from include path (!)

Just some minor changes in ArduinoCore-Linux, to replace all include from ArduinoCore-API/api from simple form "*.h" to <api/*.h> (this is the way ArduinoCore-API/tests does it, so it makes ArduinoCore-Linux consistent with ArduinoCore-API):

See my commit:
openlab-vn-ua@f0b934d

As for test/CMakeLists.txt let it be single difference, we will find solution for this later.

Looks like we about to land this thing!
I will resync our repo head with your code and try to make pull request for this for your review.

[SergeAgeyev]

Just verified existing Arduino core implementation for rpi pico:

tree structure is:

cores/rp2040/api/ <- ArduinoCore-API/api (generic core part) *.c* and *.h files from 
cores/rp2040/ <- Implementation files, like Arduino.h, HardwareSerial.h, HardwareSerial.cpp
cores/rp2040/lib../ <- Implementation-related libraries

BTW in implementation files they use "api/Common.h" references, so only path to the root of core is nessesary...

[pschatzmann]

I had a closer look at this solution approach and it's working with the current functionality and examples, but I am afraid, I don't like it because it is breaking a lot of funcitonality:

In Arduino we expect that something like #include "Stream.h" or #include "Print.h" is working to include the core functionality in a sketch.

After applying the recommendation from Arduino, we would need to use #include "api/Stream.h" or #include "api/Print.h", which is clearly wrong!

[SergeAgeyev]

Just in case you mentioned, these are trampoline modules that are put in core/api/deprecated folder.
And this folder is added to include path. This is kinda of official trick that is done in all cores.
So you can use #include "Stream.h" in you code :)

[pschatzmann]

Agreed, for Print and String this is working.
I created the String branch to be able to test this further.

If I don't get any errors in the AudioTools, I will consider this solution.

[pschatzmann]

I merged the branch to main: the core is a git submodule now.
The build works w/o errors: however I am getting errors in Github Actions now!

[SergeAgeyev]

I am fixing it, seems almost done

[SergeAgeyev]

Submodule works for Windows flawlessly!
Absolute amazing stuff!

[SergeAgeyev]

The problem with git action, that we forget to checkout submodules, so ArduinoCore-API folder is just empty :)