[flang] [mlir] Avoid clobbering mlir-tblgen target by defining dummy imported targets

[Acture]

This patch addresses an issue where MLIRConfig.cmake overrides MLIR_TABLEGEN_EXE, breaking downstream sandboxed builds (e.g., in Nix).

Specifically, this occurs when mlir-tblgen is not yet defined, and MLIRConfig redefines the target unconditionally.

This patch introduces dummy IMPORTED GLOBAL targets for mlir-tblgen and MLIR-TBLGen in flang/CMakeLists.txt, which prevents redefinition by MLIRConfig.cmake.

Motivation:
• Prevents fragile behavior in downstream builds
• Fixes out-of-tree build failures when overriding MLIR_TABLEGEN_EXE
As described in #150986

Notes:
• This patch is minimal and non-invasive; it affects only Flang.
• A more principled fix may involve changes in MLIR itself to respect overrides

Happy to revise this or upstream a more general solution to MLIR if preferred.

[github-actions]

Thank you for submitting a Pull Request (PR) to the LLVM Project!

This PR will be automatically labeled and the relevant teams will be notified.

If you wish to, you can add reviewers by using the "Reviewers" section on this page.

If this is not working for you, it is probably because you do not have write permissions for the repository. In which case you can instead tag reviewers by name in a comment by using @ followed by their GitHub username.

If you have received no comments on your PR for a week, you can request a review by "ping"ing the PR by adding a comment “Ping”. The common courtesy "ping" rate is once a week. Please remember that you are asking for valuable time from other developers.

If you have further questions, they may be answered by the LLVM GitHub User Guide.

You can also ask questions in a comment on this PR, on the LLVM Discord or on the forums.

[Acture]

Would appreciate it if someone from the MLIR or Flang team could take a look.
@llvm/pr-subscribers-mlir

[Acture]

Would appreciate it if someone from the MLIR or Flang team could take a look. @llvm/pr-subscribers-mlir

@katrak @akuhlens @DanielCChen @eugeneepshteyn
Sorry for the direct ping. Not sure if tag works—please let me know if there's a more appropriate reviewer.

[akuhlens]

@vzakhari normally I would ping @jeanPerier or @clementval but I think they are both on vacation right now. Is this something you are knowledgeable about?

[Acture]

@vzakhari normally I would ping @jeanPerier or @clementval but I think they are both on vacation right now. Is this something you are knowledgeable about?

I’m not very familiar with Flang or MLIR internals—I just encountered the issue while trying to package Flang in Nix, and the current workaround seems to build fine both locally and on CI.

Happy to leave this open and revisit once they’re back from vacation in case a more appropriate fix is needed.

[clementval]

Can you describe how do you set up flang downstream? We have couple of downstream projects and I have never seen any issue regarding mlir-tblgen. Are you building flang as standalone or within the mono repo?

[Acture]

Can you describe how do you set up flang downstream? We have couple of downstream projects and I have never seen any issue regarding mlir-tblgen. Are you building flang as standalone or within the mono repo?

I’m trying to build Flang as a standalone project within a Nix sandbox, rather than from the full LLVM monorepo.
In this setup, I encountered an issue with mlir-tblgen: although I explicitly set MLIR_TABLEGEN_EXE to the path of the binary produced by a prior Nix build of tablegen, the definition appears to be overridden during CMake configuration.

From what I can tell, the CMake logic within Flang (or its MLIR dependencies) treats mlir-tblgen as a build target rather than an imported executable. This causes the system to ignore the externally provided binary and instead expect mlir-tblgen to be built as part of the current project. While this works in monorepo-based downstreams, it breaks in sandboxed or decoupled setups like Nix, where dependencies must be pre-built and explicitly declared.

A previous nix PR also ran into a similar issue when trying to externalize tablegen executables—it seems this behavior is somewhat hardcoded and not easy to override cleanly.

[Acture]

Can you describe how do you set up flang downstream? We have couple of downstream projects and I have never seen any issue regarding mlir-tblgen. Are you building flang as standalone or within the mono repo?

I’m trying to build Flang as a standalone project within a Nix sandbox, rather than from the full LLVM monorepo.
In this setup, I encountered an issue with mlir-tblgen: although I explicitly set MLIR_TABLEGEN_EXE to the path of the binary produced by a prior Nix build of tablegen, the definition appears to be overridden during CMake configuration.

From what I can tell, the CMake logic within Flang (or its MLIR dependencies) treats mlir-tblgen as a build target rather than an imported executable. This causes the system to ignore the externally provided binary and instead expect mlir-tblgen to be built as part of the current project. While this works in monorepo-based downstreams, it breaks in sandboxed or decoupled setups like Nix, where dependencies must be pre-built and explicitly declared.

A previous nix PR also ran into a similar issue when trying to externalize tablegen executables—it seems this behavior is somewhat hardcoded and not easy to override cleanly.

[clementval]

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.

[Acture]

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.

[vzakhari]

I suppose the same issue will arise if someone tries to build just mlir (without flang) with a Nix sandbox, so it seems it is worth a more general fix for mlir. I must admit, I still do not understand what happens in your build process, so I hope a more general mlir fix will attract reviewers who understand this change.

[Acture]

I suppose the same issue will arise if someone tries to build just mlir (without flang) with a Nix sandbox, so it seems it is worth a more general fix for mlir. I must admit, I still do not understand what happens in your build process, so I hope a more general mlir fix will attract reviewers who understand this change.

That’s the odd part — building mlir with Nix works fine on my end. The problem only shows up when building flang without a dummy target, where it fails with:
ninja: error: 'include/flang/Optimizer/Dialect/CUF/Attributes/mlir-tblgen', needed by 'include/flang/Optimizer/Dialect/CUF/Attributes/CUFEnumAttr.h.inc', missing and no known rule to make it
It seems the breakage is specific to flang’s build setup rather than mlir in isolation, which I suspect is due to a missing tablegen definition, resulting in no generated output.

[clementval]

Thanks @vzakhari to chime in. I must admit as well that I don't really get the issue 100% as well. It would be good to try to bring in some MLIR cmake folks to chime in.

include/flang/Optimizer/Dialect/CUF/Attributes/mlir-tblgen This path looks kind of weird by the way.

[Acture]

Thanks @vzakhari to chime in. I must admit as well that I don't really get the issue 100% as well. It would be good to try to bring in some MLIR cmake folks to chime in.

include/flang/Optimizer/Dialect/CUF/Attributes/mlir-tblgen This path looks kind of weird by the way.

I believe a similar dependency ordering issue was reported and addressed previously — see #92635 (and its follow-up #92751). I suspect the current failure is a recurrence of that case due to a missing CMake dependency in MLIR/Flang's CUF/Attributes generation.

[clementval]

That seems to be a different error that you are hitting. mlir-tblgen is looked for in the main flang CMake file. How do you set LLVM_TOOLS_BINARY_DIR in your case?

[Acture]

That seems to be a different error that you are hitting. mlir-tblgen is looked for in the main flang CMake file. How do you set LLVM_TOOLS_BINARY_DIR in your case?

I set LLVM_TOOLS_BINARY_DIR to the bin directory produced by the tblgen-only build (${buildLlvmTools.tblgen}/bin).
I also tried pointing it to the bin directories from the libllvm package (${libllvm.out}/bin) and the full llvm build (${llvm.out}/bin), but none of them worked.

[clementval]

I set LLVM_TOOLS_BINARY_DIR to the bin directory produced by the tblgen-only build (${buildLlvmTools.tblgen}/bin). I also tried pointing it to the bin directories from the libllvm package (${libllvm.out}/bin) and the full llvm build (${llvm.out}/bin), but none of them worked.

mlir-tblgen is in the install of MLIR. Did you make sure you have this binary in one of the path you tried to use?

[Acture]

I set LLVM_TOOLS_BINARY_DIR to the bin directory produced by the tblgen-only build (${buildLlvmTools.tblgen}/bin). I also tried pointing it to the bin directories from the libllvm package (${libllvm.out}/bin) and the full llvm build (${llvm.out}/bin), but none of them worked.

mlir-tblgen is in the install of MLIR. Did you make sure you have this binary in one of the path you tried to use?

I’ve just double-checked. In the Nix build setup the situation is a bit different: the tblgen tools are split into a dedicated output, so mlir-tblgen does not appear in the MLIR “install” tree. Concretely:

# From the tblgen build (${buildLlvmTools.tblgen}/bin):
$ ls /nix/store/5hynj7y0y5pjdfyfg6hhxi9f5mpxgl6p-mlir-20.1.6/bin/
mlir-linalg-ods-yaml-gen*        mlir-pdll-lsp-server*            mlir-rewrite*                    tblgen-lsp-server*
mlir-lsp-server*                 mlir-query*                      mlir-runner*                     update_core_linalg_named_ops.sh*
mlir-opt*                        mlir-reduce*                     mlir-translate*

# From the MLIR install output (${mlir.out}/bin)
$ ls  /nix/store/pfcxcpmhxc4944dd5pw9kx3fnla9vbzm-llvm-tblgen-20.1.6/bin/
clang-tblgen*                    llvm-lit*                        llvm-tblgen*                     update_core_linalg_named_ops.sh*
clang-tidy-confusable-chars-gen* llvm-min-tblgen*                 mlir-tblgen*

Are there any other expectations that I should satisfy for Flang’s configure step?