make/esptool: fix FFLAGS inclusion order for qemu #16059
Merged
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.
Contribution description
This PR fixes the inclusion order of FFLAGS with the esptool when using the
esp_qemu
module. In master, this is currently broken (probably because of #15475).The fix proposed by this PR is to move the logic from esp32 to esptool.inc.mk, which is now included after the cpu Makefile.include is included.
This PR is a quick fix and IMHO a more proper fix is to reuse the EMULATE=1 variable and integrate the esp emulator into the qemu.inc.mk mechanism, instead of relying on the module mechanism. I leave this as a follow-up.
Another cleanup that is worth is to get rid of all this commands configured in the FFLAGS variable, this is an abuse of this variable that should only contain parameters of the flasher tool (configured in FLASHER). I'm also leaving this as a follow-up.
Testing procedure
this PR:
master:
=> one can see that the
cp
commands related to qemu are called before the other commands configured in the FFLAGS, so, right afterdd
, which is the flasher in this case. This is why it fails badly.Issues/PRs references
Noticed that problem while working on #15970