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

[christopherbate]

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

[burmako]

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

[ddunl]

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

[christopherbate]

@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]

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]

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!