[flang-commits] [flang] [flang] [mlir] Avoid clobbering mlir-tblgen target by defining dummy imported targets (PR #150987)

[via flang-commits]

Acture wrote:

> We have a standalone builedbot that should pretty much do the same thing. I'm wondering what would be the difference with your setup. I also know couple of flang developers that use the standalone build without problem. 

Thanks — I think the main difference lies in the degree of decoupling. My setup treats Flang's dependencies (e.g. mlir & mlir-tblgen) as fully externalized and pre-built artifacts, with no shared build context or target resolution beyond what’s explicitly declared.

To clarify: I’ve also built Flang standalone locally (outside of Nix) without any issues — so the build logic itself is mostly fine. The problem only arises under strict sandboxing, where tools like mlir-tblgen are treated as  given binaries/libraries and cannot be re-resolved or rebuilt.

>From what I could see, many standalone builds still implicitly rely on monorepo-style resolution, where executables are either in the same CMake project or recoverable via relative paths or internal targets. That assumption doesn’t hold in Nix, and any attempt by the build system to override explicitly set paths (like MLIR_TABLEGEN_EXE) leads to failure.

This distinction might not show up in CI setups that mirror the monorepo layout or share artifacts — but it becomes immediately visible in fully decoupled, isolated builds that enforce strict dependency declarations.

https://github.com/llvm/llvm-project/pull/150987