undefined reference to `app_main' with native build about esp-idf-sys HOT 3 CLOSED

UPDATE: Turns out even binstart is not a default now. Text updated accordingly.

Having an app_main symbol defined by default is a tricky topic. For one, esp-idf-sys (and its friends like esp-idf-hal, esp-idf-svc) might be pulled in as a dependency in CMake-first/PIO-first projects with a mixed C/Rust codebase, where the app_main symbol might already be defined in C, and the developer might want to leave it like that.

With that said, we do have the means here to automatically define an app_main symbol, which does call a Rust main symbol that the user should provide. This start.rs code currently lives in the esp-idf-svc crate however, and that's one of the main questions we should address.

It works as follows:

• If you are building a STD binary crate (typical case for cargo-first builds), the above code gets triggered, but you have to opt-in by enabling the binstart feature.
• If you are building a library crate (the usual scenario for CMake-first and PIO-first projects), binstart cannot be utilized, as it works for binary crates only. Instead, there is a libstart feature. It has less features compared to binstart but it still might be useful. The user should opt-in into that, just like with binstart.

With all of the above said... the questions are:

• Shall we move the start.rs code from esp-idf-svc to esp-idf-sys? Perhaps yes, because even though esp-idf-sys is supposed to model the ESP-IDF unsafe API only, it already does have a few small utilities, and furthermore, it models the building and linking of ESP-IDF builds too, so perhaps start.rs belongs here. Jut like the panic_handler definition is already here. Btw it should also be protected by a feature flag, as the user might want to override it.
• Shall we have the binstart feature enabled by default (it is not, currently)? Perhaps yes, as this gives more ergonomics to cargo-first projects that do build a binary crate, at the expense of less ergonomics for CMake-first and PIO-first projects that currently cannot use the default feature of esp-idf-sys (currently esp-idf-svc) because of that default, which makes sense only when building binary crates in Rust.

from esp-idf-sys.

I had to patch esp-idf-sys anyway (due to your atomics fixes pushed to ESP-IDF master now, yay!) so I decided to bite the bullet and moved binstart to esp-idf-sys. You still need to enable it with esp-idf-sys = { version = .., features = ["binstart"] } though.

The alloc handler and the panic handler are now guarded with explicit features and not enabled by default for no_std.

from esp-idf-sys.

Closing. I feel the user having to opt-in for binstart (or libstart) is somehow the best possible compromise ATM, and it's very easy to do so. Feel free to reopen if you think otherwise.

from esp-idf-sys.