tensorflow/mlir-hlo

[cmake build] MhloDialect target no longer carries correct binary include dir

christopherbate opened this issue · 5 comments

After this latest change to mlir-hlo/mhlo/CMakeLists.txt, the MhloDialect target no longer has the correct binary include directories attached to its INTERFACE_INCLUDE_DIRECTORIES. I now have to do the following in my downstream project when building mlir-hlo via the "LLVM External Project" route:

get_target_property(mhlo_includes_ MhloDialect INTERFACE_INCLUDE_DIRECTORIES)
list(APPEND mhlo_includes_ $<BUILD_INTERFACE:${LLVM_BINARY_DIR}/tools/mlir-hlo>)
set_target_properties(MhloDialect PROPERTIES INTERFACE_INCLUDE_DIRECTORIES "${mhlo_includes_}")

Otherwise, the build will fail on downstream targets that depend on MhloDialect. The compiler will say:

 fatal error: 'mhlo/IR/hlo_ops_enums.h.inc' file not found

Note that this is different from #52 (which probably can now be closed).

Edit: fixed the workaround

Hi @christopherbate! Thank you for reporting.
@ddunl Can you take a look please?

ddunl commented

Thanks for bringing this to my attention! @christopherbate can you let me know if d391887 fixes this?

@ddunl Thanks for your response. This actually doesn't fix it (in LLVM External Project mode).

I added a print statement like this:

message(WARNING "MHLO DIRS: ${MLIR_HLO_SOURCE_DIR} ${MLIR_HLO_GEN_INCLUDE_DIR}")
target_include_directories(MhloDialect
  PUBLIC
  $<BUILD_INTERFACE:${MLIR_HLO_SOURCE_DIR}>
  $<BUILD_INTERFACE:${MLIR_HLO_GEN_INCLUDE_DIR}>
)

and MLIR_HLO_GEN_INCLUDE_DIR points to something like "build/llvm/tools/mlir-hlo/include" but actually the build tree under build/llvm/tools/mlir-hlo doesn't have an include directory.

ddunl commented

Ah I was clearly not being careful enough when I made that change. I'll test a fix more thoroughly tomorrow. So sorry this is taking so long to get resolved!

ddunl commented

Woops, didn't intend for this to be closed. Let me know if a170d81 fixes this. I had a hard time finding a project using LLVM External Project mode, but I was able to replicate the faulty path using that message(...) line, and it appears to be fixed. Sorry about this!