Providing configuration for gollvm about llvm-bazel HOT 9 CLOSED

I don't have any context on gollvm, but I can provide some context on this repository and Bazel build files for LLVM.

We are working on moving these files upstream (https://groups.google.com/g/llvm-dev/c/dcis1ebRw28/m/gSTteiuVAQAJ), so this repository hasn't seen many updates in terms of structure and such.

The most logical place to add build files for gollvm would be in that repository itself. I wouldn't host them separately here (or in the LLVM monorepo if/when these move there).

Also, your Bazel invocation

bazel build --config=generic_clang @llvm-project//gollvm

doesn't make much sense to me given that you cloned gollvm under llvm/tools. The package path to it would then be @llvm-project//llvm/tools/gollvm.

from llvm-bazel.

I tried to trigger

bazel build --config=generic_clang @llvm-project//gollvm

but got

$ bazel build --config=generic_clang @llvm-project//gollvm
Extracting Bazel installation...
Starting local Bazel server and connecting to it...
DEBUG: /home/oceanfish81/.cache/bazel/_bazel_oceanfish81/55a872b9f7a9d080eacfbed36bfc6f31/external/bazel_toolchains/rules/rbe_repo/version_check.bzl:68:14:
Current running Bazel is ahead of bazel-toolchains repo. Please update your pin to bazel-toolchains repo in your WORKSPACE file.
DEBUG: /home/oceanfish81/.cache/bazel/_bazel_oceanfish81/55a872b9f7a9d080eacfbed36bfc6f31/external/bazel_toolchains/rules/rbe_repo/checked_in.bzl:125:14: rbe_default not using checked in configs; Bazel version 4.0.0 was picked/selected but no checked in config was found in map {"0.20.0": ["8.0.0"], "0.21.0": ["8.0.0"], "0.22.0": ["8.0.0", "9.0.0"], "0.23.0": ["8.0.0", "9.0.0"], "0.23.1": ["8.0.0", "9.0.0"], "0.23.2": ["9.0.0"], "0.24.0": ["9.0.0"], "0.24.1": ["9.0.0"], "0.25.0": ["9.0.0"], "0.25.1": ["9.0.0"], "0.25.2": ["9.0.0"], "0.26.0": ["9.0.0"], "0.26.1": ["9.0.0"], "0.27.0": ["9.0.0"], "0.27.1": ["9.0.0"], "0.28.0": ["9.0.0"], "0.28.1": ["9.0.0"], "0.29.0": ["9.0.0"], "0.29.1": ["9.0.0", "10.0.0"], "1.0.0": ["9.0.0", "10.0.0"], "1.0.1": ["10.0.0"], "1.1.0": ["10.0.0"], "1.2.0": ["10.0.0"], "1.2.1": ["10.0.0"], "2.0.0": ["10.0.0"], "2.1.0": ["10.0.0"], "2.1.1": ["10.0.0", "11.0.0"], "2.2.0": ["11.0.0"], "3.0.0": ["11.0.0"], "3.1.0": ["11.0.0"], "3.2.0": ["11.0.0"], "3.3.0": ["11.0.0"], "3.3.1": ["11.0.0"]}
ERROR: Skipping '@llvm-project//gollvm': no such package '@llvm-project//gollvm': BUILD file not found in directory 'gollvm' of external repository @llvm-project. Add a BUILD file to a directory to mark it as a package.
WARNING: Target pattern parsing failed.
ERROR: no such package '@llvm-project//gollvm': BUILD file not found in directory 'gollvm' of external repository @llvm-project. Add a BUILD file to a directory to mark it as a package.
INFO: Elapsed time: 17.424s
INFO: 0 processes.
FAILED: Build did NOT complete successfully (0 packages loaded)

from llvm-bazel.

Yeah as I said, that result is not surprising. There is no directory gollvm under llvm-project and there are no build files for gollvm that I'm aware of

from llvm-bazel.

Let's say that is possible to compress the whole build folder, for gollvm.
There are tested scenarios for CMake generators: for make and for Ninja.
Would that help, in case if I would supply a verbose log?

from llvm-bazel.

Sorry, I don't understand the question. I think the correct place to put Bazel build files for gollvm, would be in that project itself. It would make sense if those build files depended on these ones, although note that the precise structure of these build files might be about to change if they are successfully upstreamed to the LLVM monorepo. They would then live under llvm/utils/bazel. The thing where gollvm is checked out within the LLVM repository is strange to me. I would expect instead that it would have an LLVM submodule that it could reference, but I'm sure a Bazel build could be made to work either way.

from llvm-bazel.

@thanm, please join the discussion

from llvm-bazel.

I agree with @GMNGeoffrey , if someone is to write bazel rules, it would be in the gollvm project itself. gollvm is an "out of tree" LLVM project.

The gollvm checkout location (inside llvm/tools) is a holdover from the pre-monorepo days. It would not be especially difficult to move it to living outside of llvm/, just would require some changes to the gollvm cmake sources.

from llvm-bazel.

The main problem is how to get rid of CMake, so it would be some form of alternative.
Hence that the actual LLVM's source files, required for building llvm-goc, could be form in some way.

What I am not sure about is whether there should be some script, that would generate the of concrete files - or that has to be some pre-stage (might be some form of Github's "release" artifacts, for gollvm - could be auto-generated on each build, additionally to/aside of a compressed installation archive) task, that would de-facto use CMake (but would allow to avoid CMake, for end-users, when using Bazel).

gollvm itself is super dependent on LLVM's source code structure, in the current form - so it makes sense to diversify the build pipeline. This is one of known limitations, for people that would be interested to try gollvm.

from llvm-bazel.

Sorry I'm still not really following the details of what you're talking about, but I think this is squarely a project for gollvm and its maintainers. Please feel free to submit updates to these build files that will help with the build of gollvm (although note again that their structure may change soon).

from llvm-bazel.