Bake iree-compile path into binary at build time#245
Merged
sjain-stanford merged 3 commits intoiree-org:mainfrom Mar 13, 2026
Merged
Conversation
Previously, `getIreeCompilePath()` only checked the `FUSILLI_EXTERNAL_IREE_COMPILE` env var at runtime, falling back to a bare `"iree-compile"` string that relies on the shell PATH. This caused test failures (`sh: 1: iree-compile: not found`) when iree-compile wasn't on PATH, even though CMake already knew its location via the `FUSILLI_EXTERNAL_IREE_COMPILE` cache variable. This follows the same pattern used for `libIREECompiler.so`: `IREE_COMPILER_LIB` (CMake var) is baked into `FUSILLI_DEFAULT_IREE_COMPILER_LIB` (compile definition) so the binary can find the library at runtime without LD_LIBRARY_PATH. Now `iree-compile` gets the same treatment: - CMake bakes the resolved path into `FUSILLI_DEFAULT_IREE_COMPILE` via `target_compile_definitions` - `getIreeCompilePath()` checks: env var > compile definition > PATH The lookup precedence for both tools is now: | Tool | Env var (runtime override) | Compile definition (build-time default) | |-------------------|-------------------------------------|------------------------------------------| | libIREECompiler | FUSILLI_EXTERNAL_IREE_COMPILER_LIB | FUSILLI_DEFAULT_IREE_COMPILER_LIB | | iree-compile | FUSILLI_EXTERNAL_IREE_COMPILE | FUSILLI_DEFAULT_IREE_COMPILE | Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com> Signed-off-by: MaheshRavishankar <mahesh.ravishankar@gmail.com>
MaheshRavishankar
force-pushed
the
users/MaheshRavishankar/fixIREECompilePaths
branch
from
1d43b2f to
fa1383d
Compare
sjain-stanford
approved these changes
Mar 13, 2026
sjain-stanford
approved these changes
Mar 13, 2026
Member
sjain-stanford
left a comment
sjain-stanford
left a comment
There was a problem hiding this comment.
It mirrors what we do for libIREECompiler.so (just for PATH instead of LD_LIBRARY_PATH) so LGTM.
MaheshRavishankar
deleted the
users/MaheshRavishankar/fixIREECompilePaths
branch
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Previously,
getIreeCompilePath()only checked theFUSILLI_EXTERNAL_IREE_COMPILEenv var at runtime, falling back toa bare
"iree-compile"string that relies on the shell PATH. Thiscaused test failures (
sh: 1: iree-compile: not found) wheniree-compile wasn't on PATH, even though CMake already knew its
location via the
FUSILLI_EXTERNAL_IREE_COMPILEcache variable.This follows the same pattern used for
libIREECompiler.so:IREE_COMPILER_LIB(CMake var) is baked intoFUSILLI_DEFAULT_IREE_COMPILER_LIB(compile definition) so thebinary can find the library at runtime without LD_LIBRARY_PATH.
Now
iree-compilegets the same treatment:FUSILLI_DEFAULT_IREE_COMPILEvia
target_compile_definitionsgetIreeCompilePath()checks: env var > compile definition > PATHThe lookup precedence for both tools is now:
Co-Authored-By: Claude Opus 4.6 noreply@anthropic.com