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
Fix: esptool_py incorrectly assumed target name equals binary name (IDFGH-11420) #12558
Fix: esptool_py incorrectly assumed target name equals binary name (IDFGH-11420) #12558
Conversation
Thanks for the fix @itavero! We can't merge the PR as is, because we have to first make the fix in the |
fbdcdc2
to
5293eff
Compare
👋 Welcome itavero, thank you for your first contribution to 📘 Please check Contributions Guide for the contribution checklist, information regarding code and documentation style, testing and other topics. 🖊️ Please also make sure you have read and signed the Contributor License Agreement for espressif/esp-idf project. Pull request review and merge process you can expectEspressif develops the ESP-IDF project in an internal repository (Gitlab). We do welcome contributions in the form of bug reports, feature requests and pull requests via this public GitHub repository.
|
@igrr I've rebased it on |
sha=5293eff4cdd8545266bafdec6fe98522bbaf9c28 |
From: Arno Moonen <arno.moonen@airios.eu> Follows original message from Arno Moonen <arno.moonen@airios.eu> While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles. Most I've been able to fix in our CMake files, however this one I could not. Most of the targets created by the esptool_py component assume that the EXECUTABLE IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary. This is however not always true. For instance, in our setup we use CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our toolchain file (both set to .elf). If we do add_executable(my_app), the target binary file would actually be my_app.elf. In order to fix this, I've updated it to use the TARGET_FILE generated expression. That way we also no longer need the EXECUTABLE_DIR IDF build property here. I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well. Note that this problem might exist in multiple places where EXECUTABLE is being used. While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the TARGET_FILE expression. To be honest the property name might be somewhat confusing as well, as it is actually the executable target. Closes #12558
From: Arno Moonen <arno.moonen@airios.eu> Follows original message from Arno Moonen <arno.moonen@airios.eu> While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles. Most I've been able to fix in our CMake files, however this one I could not. Most of the targets created by the esptool_py component assume that the EXECUTABLE IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary. This is however not always true. For instance, in our setup we use CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our toolchain file (both set to .elf). If we do add_executable(my_app), the target binary file would actually be my_app.elf. In order to fix this, I've updated it to use the TARGET_FILE generated expression. That way we also no longer need the EXECUTABLE_DIR IDF build property here. I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well. Note that this problem might exist in multiple places where EXECUTABLE is being used. While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the TARGET_FILE expression. To be honest the property name might be somewhat confusing as well, as it is actually the executable target. Closes espressif#12558
From: Arno Moonen <arno.moonen@airios.eu> Follows original message from Arno Moonen <arno.moonen@airios.eu> While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles. Most I've been able to fix in our CMake files, however this one I could not. Most of the targets created by the esptool_py component assume that the EXECUTABLE IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary. This is however not always true. For instance, in our setup we use CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our toolchain file (both set to .elf). If we do add_executable(my_app), the target binary file would actually be my_app.elf. In order to fix this, I've updated it to use the TARGET_FILE generated expression. That way we also no longer need the EXECUTABLE_DIR IDF build property here. I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well. Note that this problem might exist in multiple places where EXECUTABLE is being used. While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the TARGET_FILE expression. To be honest the property name might be somewhat confusing as well, as it is actually the executable target. Closes #12558
From: Arno Moonen <arno.moonen@airios.eu> Follows original message from Arno Moonen <arno.moonen@airios.eu> While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles. Most I've been able to fix in our CMake files, however this one I could not. Most of the targets created by the esptool_py component assume that the EXECUTABLE IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary. This is however not always true. For instance, in our setup we use CMAKE_EXECUTABLE_SUFFIX_C and CMAKE_EXECUTABLE_SUFFIX_CXX in our toolchain file (both set to .elf). If we do add_executable(my_app), the target binary file would actually be my_app.elf. In order to fix this, I've updated it to use the TARGET_FILE generated expression. That way we also no longer need the EXECUTABLE_DIR IDF build property here. I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well. Note that this problem might exist in multiple places where EXECUTABLE is being used. While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the TARGET_FILE expression. To be honest the property name might be somewhat confusing as well, as it is actually the executable target. Closes #12558
While integrating the ESP-IDF into our existing CMake structure, I've come across quite some hurdles.
Most I've been able to fix in our CMake files, however this one I could not.
Most of the targets created by the esptool_py component assume that the
EXECUTABLE
IDF build property (which contains the name of the CMake executable target) always equals the name of the created binary.This is however not always true. For instance, in our setup we use
CMAKE_EXECUTABLE_SUFFIX_C
andCMAKE_EXECUTABLE_SUFFIX_CXX
in our toolchain file (both set to.elf
).If we do
add_executable(my_app)
, the target binary file would actually bemy_app.elf
.In order to fix this, I've updated it to use the
TARGET_FILE
generated expression. That way we also no longer need theEXECUTABLE_DIR
IDF build property here.I've fixed this on v5.0.1 (as that's the ESP-IDF version I'm currently trying to integrate), but I assume it should be easy to apply the same fix to newer versions and the master branch as well.
Note that this problem might exist in multiple places where
EXECUTABLE
is being used.While going through the ESP-IDF code base, I even noticed that a few places actually already seem to use the
TARGET_FILE
expression.To be honest the property name might be somewhat confusing as well, as it is actually the executable target.