You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have updated my IDF branch (master or release) to the latest version and checked that the issue is present there.
I have searched the issue tracker for a similar issue and not found a similar issue.
General issue report
Presently the specification of a CSV file for the partition_table component gets serialized to an absolute path relative to the derived project location:
This results in a problematic composition of the path when there is more than a single level of component composition within an ESP-IDF project.
For example, I cam currently extending the MicroPython project. Within their build system, it's expected that a user will execute idf.py build from the path ports/esp32 within the project. This will then set ports/esp32/partitions.csv as the required file path.
When consuming MicroPython as a submodule and referencing the CMake scripts from another project while utilizing the same sdkconfig definition (e.g. ext/micropython/ports/esp32) due to the change in the location of the project call the definition loses portability between projects.
The text was updated successfully, but these errors were encountered:
One resolution would be to allow the user to set a property on the build. A different idea would be to use the find_file() CMake function (https://cmake.org/cmake/help/latest/command/find_file.html) with the ENV var sub-option allowing a user to specify an additional search path as a part of the build environment.
@brianredbeard Thanks for reporting the problem to us. Seems like the solution could be to have an absolute path configuration for the csv file irrespective of the project path. We shall take a look!
Answers checklist.
General issue report
Presently the specification of a CSV file for the
partition_table
component gets serialized to an absolute path relative to the derived project location:esp-idf/components/partition_table/project_include.cmake
Lines 14 to 15 in 2bc1f2f
This results in a problematic composition of the path when there is more than a single level of component composition within an ESP-IDF project.
For example, I cam currently extending the MicroPython project. Within their build system, it's expected that a user will execute
idf.py build
from the pathports/esp32
within the project. This will then setports/esp32/partitions.csv
as the required file path.When consuming MicroPython as a submodule and referencing the CMake scripts from another project while utilizing the same sdkconfig definition (e.g.
ext/micropython/ports/esp32
) due to the change in the location of theproject
call the definition loses portability between projects.The text was updated successfully, but these errors were encountered: