This is an archive of the discontinued LLVM Phabricator instance.

[mlir] Leverage CMake interface libraries for mlir python
ClosedPublic

Authored by stella.stamenova on Jun 20 2022, 3:21 PM.

Details

Summary

This is already partially the case, but we can rely more heavily on interface libraries and how they are imported/exported in other to simplify the implementation of the mlir python functions in Cmake.

This change also makes a couple of other changes:

  1. Add a new CMake function which handles "pure" sources. This was done inline previously
  2. Moves the headers associated with CAPI libraries to the libraries themselves. These were previously managed in a separate source target. They can now be added directly to the CAPI libraries using DECLARED_HEADERS.
  3. Cleanup some dependencies that showed up as an issue during the refactor

This is a big CMake change that should produce no impact on the build of mlir and on the produced *build tree*. However, this change fixes an issue with the *install tree* of mlir which was previously unusable for projects like torch-mlir because both the "pure" and "extension" targets were pointing to either the build or source trees.

Diff Detail

Event Timeline

stella.stamenova requested review of this revision.Jun 20 2022, 3:21 PM
stellaraccident accepted this revision.Jun 23 2022, 5:23 PM

Thank you for this. As we discussed on Discord, I didn't know about the inheritable sources on interface libraries, and that simplifies things. A couple of comments for my own education, but otherwise looks good.

Have you happened to have tested this with a downstream yet?

mlir/cmake/modules/AddMLIRPython.cmake
79

Aha -- it never even occurred to me that CMake interface libraries also had inheritable sources. This does simplify things.

83

I'm a bit surprised that you also need to specify PRIVATE sources. Is this just some CMake thing that I should look past and not question too deeply?

mlir/python/CMakeLists.txt
505

Is this something that we need to instruct downstreams to adapt to or just a cleanup while you were here? If the former, can you leave some notes for downstreams in the commit description?

This revision is now accepted and ready to land.Jun 23 2022, 5:23 PM
stella.stamenova edited the summary of this revision. (Show Details)Jun 24 2022, 9:42 AM

Thank you for this. As we discussed on Discord, I didn't know about the inheritable sources on interface libraries, and that simplifies things. A couple of comments for my own education, but otherwise looks good.

Have you happened to have tested this with a downstream yet?

I made sure torch-mlir can build/test/install correctly both with a build and an install tree of mlir. I haven't tested other downstreams.

mlir/cmake/modules/AddMLIRPython.cmake
83

I tried to capture this in the comment in the cmake file, but let me know if you'd like me to add any more to it:

Basically, the reason we need the PRIVATE sources here is that BUILD_INTERFACE and INSTALL_INTERFACE expressions get evaluated at *build* time, but for the copying/symlinking of the source files all steps happen at *configuration* time, so the expressions are not evaluated yet and are useless. The PRIVATE sources, on the other hand, can be used at configuration time. When pointing to a build or an install mlir tree for downstream projects, both the generator expressions are evaluated correctly, so the interface sources work fine.

There are ways we could do away with the PRIVATE sources, but it would make the rest of the logic more complicated and I decided it wasn't worth it. Once we have FILE_SETs, this can be cleaned up somewhat if there's a need.

mlir/python/CMakeLists.txt
505

I'll add a bit more details to the commit description.

When I was going through this, I noticed that we declared the header sources in a separate target from the library that uses them, so I decided to make them depend on each other. This means that the CAPI libraries will always have any headers they need if they use the new DECLARED_HEADERS option. They don't have to, though, so downstreams can continue to do it differently if they want to. It would be better if they didn't, but it should work correctly in most cases regardless.

Thank you for this. As we discussed on Discord, I didn't know about the inheritable sources on interface libraries, and that simplifies things. A couple of comments for my own education, but otherwise looks good.

Have you happened to have tested this with a downstream yet?

I made sure torch-mlir can build/test/install correctly both with a build and an install tree of mlir. I haven't tested other downstreams.

Thanks - verifying torch-mlir should be enough. They all build off of that pattern. Good enough for me. Thanks.

mlir/cmake/modules/AddMLIRPython.cmake
83

Oh cmake. Thanks, i thinki get it now.

mlir/python/CMakeLists.txt
505

Ok, thanks for the explanation. I mainly want to ensure that if we change how downstreams need to do it that we document so they can adapt when they integrate.

FYI - this patch has a minor bug in it when used as part of larger projects. Line 214 creates duplicate target names in some cases. It needs to be scoped (like is done for the target just below it).

set(_pure_sources_target "${modules_target}.sources.${sources_target}")

Since this seems very specific to some tricky downstreams that are debugged ins-situ, I'm just going to push a quick fix.

FYI - this patch has a minor bug in it when used as part of larger projects. Line 214 creates duplicate target names in some cases. It needs to be scoped (like is done for the target just below it).

set(_pure_sources_target "${modules_target}.sources.${sources_target}")

Since this seems very specific to some tricky downstreams that are debugged ins-situ, I'm just going to push a quick fix.

Thanks!

FYI - Another downstream issue fixed: https://reviews.llvm.org/D129434