-
-
Notifications
You must be signed in to change notification settings - Fork 799
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
include in build_flags expands path when it should not expand #4683
Comments
@ivankravets This is a major bug. It breaks project Tasmota completely and every other project that does something like this
How can we force to use PIO Core v6.1.7 as fast fix? |
Yep, also broke ESPEasy builds....
You could perhaps enforce a specific version of Platformio in the requirements.txt file? |
Sorry, the hot fix 6.1.9 is coming. |
Please re-test the latest development version ( |
Build succeeds for me in the ELRS Configurator with |
Just wondering, how to define such an unreleased version in requirements.txt? |
Just pass
|
Sorry, my typo. See syntax https://pip.pypa.io/en/stable/reference/requirements-file-format/ This should work:
|
As the first env completed already, I think it did indeed fix the builds again. |
Can confirm. Latest development version does work. |
Big THANKS for the confirmation. 6.1.9 is coming! |
Yup I woke up and installed the dev version (which ended up being 6.1.10) which worked, rolled back to the release 6.1.9 (which was released 8 minutes earlier) and it also works again. Thank you! |
What kind of issue is this?
If you’ve found a bug, please provide an information below.
Configuration
Operating system:
Windows 10 Pro 22H2 19045.3086
PlatformIO Version (
platformio --version
):PlatformIO Core, version 6.1.8
PlatformIO Core, version 6.1.9a1
Description of problem
A continuation of #4682, when an environment's
build_flags
contains an-include
item with a relative path and the file is in gcc's include path, the build fails as the builder has converted the relative path into an invalid absolute one. The difference between this and #4682 is that issue had a variable in it that needed to be expanded, and this is strictly a relative path to an item in the gcc include path. The documentation states that-include
:However, in 6.1.8 this has changed as the build process now replaces any
-include
with an absolute path, even when the path is not valid. In 6.1.7 and previous versions the following flags workbuild_flags = -Iinclude -include XXX.h
if XXX.h is in${PROJECT_DIR}/include
. The path to XXX.h gets expanded in 6.1.8 to the builder directory:Setting the
build_flags = -include "${PROJECT_DIR}/include/XXX.h
does not work in 6.1.8 as the variable is not expanded, and in 6.1.9a1 the variable is expanded (thanks to 01ab1fa), but it is not backward compatible with the previous versions, or the documentation. Also working isbuild_flags = -include include/XXX.h
Our project supports building older versions as well, meaning we'd have to cut new releases for all our old versions just due to this incompatibility.
Suggested Fix
Perhaps the include can just not expand the path if the generated absolute path does not exist?
builder.py
Additional info
I'm sorry I do not have a simple project to reproduce this issue, as our project is somewhat large and I'd have to start something from scratch. This is the project:
https://github.com/ExpressLRS/ExpressLRS/
The text was updated successfully, but these errors were encountered: