Missing functions in host mocking

[everslick]

I tried to build my rather comprehensive firmware using the host mocking and encountered the following missing functions in the linking stage of the build.

// IMHO critical
WiFiServer::setNoDelay(bool)
WiFiServer::status()
WiFiServer::stop()

// IMHO nice to have
spi_flash_read()
spi_flash_erase_sector()
spi_flash_write()

What is the general consensus here? Is having a complete API for host builds a target or should only the minimum API be supported to make the CI test build? I really would love to have a native build of my firmware for testing non HW dependent features during development - this would be a killer feature. :-)

On a side note what I feel would improve this further:

• Allow configuring a build directory where object files and .gcno files are created to not pollute the source directory
• Add user .c files to the collected source files, not only .cpp and .ino

[d-a-v]

Original issue: #1715

should only the minimum API be supported to make the CI test build?

No

Is having a complete API for host builds a target ?
this would be a killer feature. :-)

Yes !

spi_flash_*()

In a file, like with eeprom and spiffs ?

Allow configuring a build directory where object files and .gcno files are created to not pollute the source directory
Add user .c files to the collected source files, not only .cpp and .ino

Using arduino builder would be the preferred way.

[everslick]

Original issue: #1715

thx!

Is having a complete API for host builds a target ?
this would be a killer feature. :-)

Yes !

fantastic.

spi_flash_*()

In a file, like with eeprom and spiffs ?

if we had spi_flash_* then we wouldn't need higher level emulation of eeprom and spiffs because those could directly come from the core and library folder. no?

[everslick]

Pending PR for the low hanging fruits: #5764 #5765 #5766

[d-a-v]

if we had spi_flash_* then we wouldn't need higher level emulation of eeprom and spiffs because those could directly come from the core and library folder. no?

Yes that could work.
In the first place, having separate files make emulation more modular, spiffs can be shared between sketches (I do that in some local tests), spiffs file could be used with host-only reader/uploader...
But yes, emulating spi would emulate eeprom, spiffs, and future to come littlefs all at once.

[everslick]

I will submit a PR for a low level uart driver tomorrow and then start working on the spi flash API if nobody else is working on it.

Thanks for the input!

[d-a-v]

Partially fixed by #5785,
Closing due to age, and because emulation on host is a constant WIP in #1715.