Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build cargo_driver: update embuild to support non-git
IDF_PATH
#353build cargo_driver: update embuild to support non-git
IDF_PATH
#353Changes from all commits
3bdb7b3
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As in the other PR (embuild), I'm struggling to understand why this line is necessary.
Can you elaborate a bit on it? How come we need it now, but we did not need it before?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
These refer to two paths with different purposes that eventually get returned on line 127:
idf_path
, theesp-idf
source directory aka$IDF_PATH
used byembuild::EspIdf
, returned asidf
idf_tools_install_dir
, the tool installation directory (no source code), returned astools_install_dir
.Before this PR, the only way to set a custom IDF checkout was to set the
$IDF_PATH
environment variable - this has been changed to useconfig.native.idf_path
, which respects both documented ways to configure ESP-IDF when constructed.Note
This change might also fix an existing bug where this config in
Cargo.toml
isn't respected? 🤔I'm happy to add a comment and/or update variable names if there's something you find clearer.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If I read this correctly, before these 2 PRs,
esp-idf-sys
would read idf_path from (a) env ofIDF_PATH
, (b)package.metadata.esp-idf-sys.idf_path
in cargo.toml.embuild
would only readIDF_PATH
from (a) env ofIDF_PATH
Suppose we specify idf_path from (b)
embuild
would never knowidf_path
is set to/path/to/my/idf-checkout
, so we need to pass this information to embuild. And now there's 2 way to achieve thisembuild::EspIdf::from_env
, as @denbeigh2000 do in this PR.std::env::set_var
, not sure if there's other side effects.@ivmarkov hope this helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, is this change OK? This way you'll also patch external, user-supplied repositories which might not be ideal (i.e. making changes to a user-supplied directory).
Why can't we just use the old logic with
is_managed_espidf
?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hm you're correct - this is checking if the dir is a git repo, instead of if it's managed by
EspIdf
. Will fix this in next commit (tomorrow?)