-
-
Notifications
You must be signed in to change notification settings - Fork 713
Fix matching of "components" dir when there's a symlink in the path to .platformio #1599
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
base: develop
Are you sure you want to change the base?
Conversation
…o .platformio compile_source_files() uses a relative path for the object if the source file is within the "components" tree. It checks the path string with .startswith(), though, and that can fail if the paths point to the same file but look different due to symlinks. In my case, it saw two different source paths in target-__idf_efuse-5f3f9f6e3513e0903efa.json: 1. /space/home/user/.platformio/packages/framework-espidf/components/efuse/esp32c6/esp_efuse_fields.c 2. /space/home/user/.platformio/packages/framework-espidf/components/efuse/src/esp_efuse_fields.c But my home directory uses a symlink, so components_dir was: - /home/user/.platformio/packages/framework-espidf/components This resulted in attempting to build the same object file for both: *** Multiple ways to build the same target were specified for: /space/home/user/git/project/esphome/.esphome/build/device/.pioenvs/device/esp_efuse_fields.c.o (from ['/space/home/user/.platformio/packages/framework-espidf/components/efuse/esp32c6/esp_efuse_fields.c'] and from ['/space/home/user/.platformio/packages/framework-espidf/components/efuse/src/esp_efuse_fields.c']) File "/home/user/.platformio/platforms/espressif32/builder/frameworks/espidf.py", line 773, in compile_source_files This fix simply resolves any symlinks in components_dir before using it for the comparison.
Hi @mhkrebs, thanks for the PR. Could you please provide instructions how to reproduce the issue? |
In my case (and in this comment), the issue is that To reproduce maybe try: cd
mv .platformio temp
ln -s temp .platformio
cd esphome
esphome compile device.yaml (BTW, I don't feel sentimental about this PR... I can believe there's a better fix for this.) |
Well the fix isn't a fix, it breaks Windows compile. |
My original fix resolved links in `components_dir`, but apparently the source paths might not be resolved themselves (at least on Windows). This fix simply resolves links in both before doing the comparison.
Alright, I updated the fix. Sorry about that. I was worried about that possibility, that the source paths might not be resolved themselves. (I'm guessing that's the issue on Windows.) I don't have Windows, but with this updated fix it still fixes my issue on Linux. I don't know how to test for Windows, but it looks like the tests will automatically run for this PR? Although, like I implied, I'm fine if somebody wants to make a better fix for this... I just want to be able to compile ESPHome. :) |
Hi, I'm running the device update in home assistant and having the same error with the latest update of ESPHome v2025.6.2:
|
compile_source_files()
uses a relative path for the object if the source file is within the "components" tree. It checks the path string with.startswith()
, though, and that can fail if the paths point to the same file but look different due to symlinks.In my case, it saw two different source paths in "target-__idf_efuse-5f3f9f6e3513e0903efa.json":
But my home directory uses a symlink, so
components_dir
was:This resulted in attempting to build the same object file for both:
This fix simply resolves any symlinks in
components_dir
before using it for the comparison.Fixes #515