Is the expectation that a user will set this themselves? That's probably fine, just a small surprise

Oh, yeah, thanks for catching.

I thought we still have options on how this libc change is used, but now I'm not sure anymore if I'm correct.

I think we have 2 options, and we have not reached a conclusion yet (esp-rs/esp-idf-sys#410, and around here: esp-rs/esp-idf-sys#408 (comment) -- @ivmarkov FYI):

1. Users will need to pass the config. esp-idf-sys already did this in the past when moving from cfg_time32 to cfg_time64. This one is a bit more annoying as technically it's still possible to choose between picolibc and newlib in esp-idf's Kconfig -- but we can detect mismatch in esp-idf-sys at build time and fail with a clear error message, so maybe this is somewhat acceptable.
   I have a prototype for this and I'm sure this can work.
2. Add a whole new toolchain (e.g. riscv32imc-esp-espidf-picolibc). I'm not 100% sure but I think this new toolchain could pass cfg_picolibc config to libc? Or do we need a different structure here (use target_env?)
   In any case , this feels almost equally painful from user side, as they'd also need to change their build files to use that new toolchain, and we still need to implement error checking in esp-idf-sys to make sure esp-idf's Kconfig matches the toolchain used.

(oh, and I guess in both cases esp-idf-sys could automatically select the proper Kconfig option based on config option -- or toolchain -- but that's orthogonal to the problem here)

Is the expectation that a user will set this themselves? That's probably fine, just a small surprise

TL;DR: Yes, the user is supposed to pass --cfg espidf_picolibc to rustc. :-)

Long story:

This is identical to how the existing espidf_time32 / espidf_time64 flags work.

@drinkcat Can you also put espidf_time64 in the list of options, as surprisingly it is not there?

I think we have 2 options, and we have not reached a conclusion yet (esp-rs/esp-idf-sys#410, and around here: esp-rs/esp-idf-sys#408 (comment) -- @ivmarkov FYI):

I confirm we have two options (Option 1: a Rust cfg flag; Option 2: duplicate all "espidf" Rust targets to have a picolibc variant).

However this PR is already doing Option 1. Which - for now - I feel is the slightly better overall option (see below) even if it feels a bit "hacky".

2. Add a whole new toolchain (e.g. riscv32imc-esp-espidf-picolibc).

I think the correct terminology is not "toolchain" but rather, a rust target.

The drama with adding new target(s) is that we have to add quite a few of those, not just one. I.e. we currently have:

• riscv32imc-esp-espidf
• riscv32imac-esp-espidf
• riscv32imafc-esp-espidf
• xtensa-esp32-espidf
• xtensa-esp32s2-espidf
• xtensa-esp32s3-espidf

I.e. 6 in total. We'll need another 6:

• riscv32imc-esp-espidf-picolibc
• riscv32imac-esp-espidf-picolibc
• riscv32imafc-esp-espidf-picolibc
• xtensa-esp32-espidf-picolibc
• xtensa-esp32s2-espidf-picolibc
• xtensa-esp32s3-espidf-picolibc

I'm not 100% sure but I think this new toolchain could pass cfg_picolibc config to libc? Or do we need a different structure here (use target_env?)

Not possible. If we go with a set of new targets (Option 2) then all branching in this PR should be done by target_env = "picolibc" (because the new targets will declare that they use picolibc instead of newlib - which is the whole benefit of going with the extra targets in the first place). Note that we might have to introduce a new env for picolibc if we go with the extra targets' option. No big deal, but just mentioning.

In any case , this feels almost equally painful from user side, as they'd also need to change their build files to use that new toolchain, and we still need to implement error checking in esp-idf-sys to make sure esp-idf's Kconfig matches the toolchain used.

That's true, though the extra targets' approach feels cleaner.
It is just that it means much more stuff to upstream (first to rustc then to libc) so I'm not sure it is worth the hassle. At least not right now. If things change, we might reconsider/revisit.

(oh, and I guess in both cases esp-idf-sys could automatically select the proper Kconfig option based on config option -- or toolchain -- but that's orthogonal to the problem here)

Nope, I don't think this is possible. Just like the Linux kernel, also ESP-IDF is Kconfig-first (i.e. the Kconfig file is "the primary source of truth"). You can't drive Kconfig with Rust options/features/cfgs, it is the other way around - you can reason - in Rust code - what was selected in Kconfig as all selections are exposed as Rust cfgs. It is just that these automatically-generated-during-esp-idf-sys-build cfgs don't reach and cannot be used in the libc code obviously.
Hence why we are introducing a "manual" one here.

Thanks for the detailed reply! Tricky stuff, appreciated ,-P

@drinkcat Can you also put espidf_time64 in the list of options, as surprisingly it is not there?

It's not in there because it's it's not used in libc. There's only 1 use for espidf_time32:

The default was flipped in 7bd7276 by @SergioGasquez -- I assume that if picolibc becomes the "usual" flag we could also introduce some espidf_newlib_legacy or something...

Ah yes, I forgot about that. You are completely right.