bazel build support

[garymm]

It'd be nice to be able to depend on this code in a project that uses Bazel.
LLVM seems to have some support for bazel, so maybe this wouldn't be too hard.

[stellaraccident]

I don't think any of the current contributors are interested in supporting such an effort -- which tends to be expensive over time. But the precedent in llvm may apply here: allowing for an unsupported place to put contributed build files.

What do you mean by "depend on"? Do you just need a c++ dependency on the dialects? Trying to get the whole python plus pytorch dependency? (I can't see how this is useful unless if you are a shop that must have all software hermetically built by bazel exclusively: just build the wheel and install it like any other python dep)

[garymm]

I'm still exploring but I at least want a C++ dependency on the dialects. Is there some way to get that in my bazel project?

[stellaraccident]

People who need this would need to implement it. It seems unlikely that it is something that contributors would do without having a need for it themselves.

I suspect there is a path for landing it on an unsupported way, given the precedent in llvm.

[silvasean]

@asaadaldien was also interested in bazel, though I don't know if the exact use case is the same.

I am okay with following LLVM precedent here of having it unsupported on the side and let those interested maintain their own build files.

[asaadaldien]

@garymm yes, you can write bazel rules for each cmake library easily with very little manual effort one caveat there is a small header circular dependency between Troch\Transforms\* && TorchConversion\ that I had to resolve.

I got everything c++ building with bazel currently wrestling with python side.

As @silvasean mentioned maybe we can add/maintain unsupported \WORKSPACE \BUILD for downstream bazel users ?

[silvasean]

@garymm yes, you can write bazel rules for each cmake library easily with very little manual effort one caveat there is a small header circular dependency between Troch\Transforms\* && TorchConversion\ that I had to resolve.

What was the issue? I would love to have the fix upstream!

[garymm]

@asaadaldien sounds like a PR adding Bazel files might be welcome, though it's not in my power to approve.

[asaadaldien]

@garymm yes, you can write bazel rules for each cmake library easily with very little manual effort one caveat there is a small header circular dependency between Troch\Transforms\* && TorchConversion\ that I had to resolve.

What was the issue? I would love to have the fix upstream!

Thanks @sean, I send out PR for what I did locally

I also got python bindings working (many thanks to @stellaraccident suggestions).

There is another small caveat here, bazel can't have a top level directory external, it works on my case because torch_mlir is dependency and not the main repo but if we want to stage something out, how do we feel about renaming e.g external --> externals ?

[silvasean]

There is another small caveat here, bazel can't have a top level directory external, it works on my case because torch_mlir is dependency and not the main repo but if we want to stage something out, how do we feel about renaming e.g external --> externals ?

Sigh. If this is a blocker I suppose we can rename it :/

[stellaraccident]

Double sigh. Bazel has incomprehensible limitations on names. Should have been rewritten instead of just exported from Google's internal systems with all of these spikey bits.

[asaadaldien]

There is another small caveat here, bazel can't have a top level directory external, it works on my case because torch_mlir is dependency and not the main repo but if we want to stage something out, how do we feel about renaming e.g external --> externals ?

Sigh. If this is a blocker I suppose we can rename it :/

I believe still an issue bazelbuild/bazel#4508 still opened, I tried the experimental flags things but doesn't seem to work on my bazel version, I a sent PR #699 for the renaming.

[asaadaldien]

I send a #706 for rules to build the compiler part, I will send followup PRs for python bindings and lit tests.

[kkiningh]

@asaadaldien, are you still planning on sending a followup PR for the python bindings?