Support for starting build in activated ESP-IDF environment

[georgik]

Use case: User deploys ESP-IDF starts the environment using export.[sh|bat|.ps1]. The script adds path to tools to PATH and configures some additional environment variables. User switches to the directory with Rust project and enters: cargo build.

Observed behavior: The build fails, because embuild attempts to clone new ESP-IDF and activates new virtual environment inside existing virtual environment which fails.

Desired behavior: The build is able to determine that it's running inside activated ESP-IDF with all variables and tools set, so it's not necessary to perform installation procedure and invokes the build with tools available on PATH.

[ivmarkov]

I'll be working on that.

[rgcottrell]

This would also be helpful in the case where the Rust code is built as a IDF component (using ExternalProject_Add) in a traditional IDF project. This would allow gradual migration of code in an existing project from C to Rust.

[ivmarkov]

This would also be helpful in the case where the Rust code is built as a IDF component (using ExternalProject_Add) in a traditional IDF project. This would allow gradual migration of code in an existing project from C to Rust.

Nope. What you are asking for is already supported. Please generate a 'cmake' project using the esp-idf-template cargo project template to see it in action.

[rgcottrell]

Nope. What you are asking for is already supported. Please generate a 'cmake' project using the esp-idf-template cargo project template to see it in action.

I think you misunderstood my comment. When cargo is run from within the context of an idf.py project, it is running by definition within an activated ESP-IDF environment and the crate should never attempt to clone and install a new IDF environment.

My project was based on an earlier version esp-idf-template before support for esp-idf-sys was added and, as a result, my build failed when I simply added the dependency. I've updated my CMakeList.txt invocation to follow the pattern set in the updated and it looks like it correctly picked up and used the active IDF environment. I'm unsure, however, which settings were necessary to properly configure this behavior.

[ivmarkov]

Nope. What you are asking for is already supported. Please generate a 'cmake' project using the esp-idf-template cargo project template to see it in action.

I think you misunderstood my comment. When cargo is run from within the context of an idf.py project, it is running by definition within an activated ESP-IDF environment and the crate should never attempt to clone and install a new IDF environment.

I don't think I misunderstood. It is just that - undortunately - there are two cases where an idf env is activated:
Case 1: Activated idf env and cargo being called from cmake. This case is supported since quite some time and this PR is not changing anything in relation to that case. For that case, you need the bindings to be generated and the sdkconfig to be parsed and the kcondig settings to be turned to to Rust cfg flags.
Case 2: idf.py environment activated, but cargo not being called from cmake, but as a standalone tool. For this case, tooling should not be installed automatically (this PR takes care of exactly that!) yet, in addition to what is done for Case 1, also the esp-idf should be built and linker flags should be passed down to the binary crate.

And there is also Case 3 also introduced with this PR, where the user has specified a custom esp idf via IDF_PATH, yet she has not activated its build environment. In that case, the crate should do it, downloading tooling as necessary.

My project was based on an earlier version esp-idf-template before support for esp-idf-sys was added and, as a result, my build failed when I simply added the dependency. I've updated my CMakeList.txt invocation to follow the pattern set in the updated and it looks like it correctly picked up and used the active IDF environment. I'm unsure, however, which settings were necessary to properly configure this behavior.

Which esp-idf-template are you referring to? The one I meant is supporting esp-idf-sys from day 1.

[rgcottrell]

I don't think I misunderstood. It is just that - undortunately - there are two cases where an idf env is activated: Case 1: Activated idf env and cargo being called from cmake. This case is supported since quite some time and this PR is not changing anything in relation to that case. For that case, you need the bindings to be generated and the sdkconfig to be parsed and the kcondig settings to be turned to to Rust cfg flags. Case 2: idf.py environment activated, but cargo not being called from cmake, but as a standalone tool. For this case, tooling should not be installed automatically (this PR takes care of exactly that!) yet, in addition to what is done for Case 1, also the esp-idf should be built and linker flags should be passed down to the binary crate.

Okay, I think there was some misunderstand of terms. I think when you talk about cargo you mean the cargo-first approach to build a full binary and cmake to mean the cmake-first approach to use idf.py to build the binary.

I was thinking about cargo just meaning running cargo to build a static library and using cmake outside of the idf.py. What we were experimenting with was some code based on the idf-as-lib example. What I wanted to happen was to use esp-idf-sys to generate bindings that could be used to build a static lib that would then be linked together with other IDF libs to create the final application binary.

Now that I know a little bit more about how this crate is intended to work, I think that this might be an unsupported use case.