fix(CI): Keep Xtensa clang environment variables off the general system #491
Conversation
chrysn
force-pushed
the
xtensa-dont-mess-with-env
branch
2 times, most recently
from
57a0f14 to
766330c
Compare
|
Turned out it did build, so the LIBCLANG_PATH (which is now stored away in _XTENSA_LIBCLANG_PATH in case anything we do needs to pull it back in) was exported completely needlessly and just broke stuff. I've rebased this PR onto #492 – originally they were distinct approaches, but with how that one turned out to just update the system, and how this one turned out to just work, both contribute to having a consistent story towards resolving the CoAP build issues (which eventually #443 should fix). |
chrysn
force-pushed
the
xtensa-dont-mess-with-env
branch
4 times, most recently
from
8ef483b to
8672b76
Compare
|
Set back to draft when I found that as tracked in actions/runner#1126, GitHub action environment variables can simply not be unset in general. |
chrysn
force-pushed
the
xtensa-dont-mess-with-env
branch
from
8672b76 to
caf286d
Compare
chrysn
force-pushed
the
xtensa-dont-mess-with-env
branch
from
caf286d to
1751b0c
Compare
|
This is now ready for review again -- it finally does something, and conveniently, the (back then unfounded) observation that the environment variable is not really needed held. |
|
Lgtm |
|
If we don't go with a squash, #443 would work as-is, and I don't think it hurts to keep this one, but if you prefer squashing, I can do that too. |
With [38] tentatively in (through a branched action), [491] can be reverted; the latter had doing something like [38] in its list of considered alternatives, but failed to foresee the need for sourcing all that data back in for compiling C code on Xtensa. [38]: esp-rs/xtensa-toolchain#38 [491]: ariel-os#491
With [38] tentatively in (through a branched action), [491] can be reverted; the latter had doing something like [38] in its list of considered alternatives, but failed to foresee the need for sourcing all that data back in for compiling C code on Xtensa. [38]: esp-rs/xtensa-toolchain#38 [491]: ariel-os#491
With [38] tentatively in (through a branched action), [491] can be reverted; the latter had doing something like [38] in its list of considered alternatives, but failed to foresee the need for sourcing all that data back in for compiling C code on Xtensa. [38]: esp-rs/xtensa-toolchain#38 [491]: ariel-os#491
Description
The Xtensa toolchain sets a general
LIBCLANG_PATH, which is part of what causes the clang troubles for libOSCORE (to be fixed in #443).This approach
unsets it from the GitHub action environment, and will later set it specifically for the ESP builds on demand.[edit: added] Now we can't unset it from the GitHub actions because that just doesn't work, but we prepare a sourceable .profile style file that is then sourced by all relevant run scripts.
Open Questions
Will it build?
[edit, added:] … and it didn't even need that environment variable anywhere else 🤦
Were alternatives considered?
Yes: The alternative is to fork the Xtensa script and make it optional to export the variable.
Or fork GitHub runners and fix Allow to unset env variables actions/runner#1126 so that we can just unset what the action sets.
But those would all be way more effort than maintaining this workaround.
PR dependencies
Depended on #492
Change checklist