Fixes:
ERROR: The project you're trying to build requires Bazel 7.3.0
(specified
in llvm-project/utils/bazel/.bazelversion), but it wasn't found in
/usr/bin.
You can install the required Bazel version via apt:
sudo apt update && sudo apt install bazel-7.3.0
If this doesn't work, check Bazel's installation instructions for help:
https://bazel.build/install/ubuntu
Link: https://blog.bazel.build/2024/12/09/bazel-8-release.html
This PR allows out-of-tree dialects to write Python dialect modules
using nanobind instead of pybind11.
It may make sense to migrate in-tree dialects and some of the ODS Python
infrastructure to nanobind, but that is a topic for a future change.
This PR makes the following changes:
* adds nanobind to the CMake and Bazel build systems. We also add
robin_map to the Bazel build, which is a dependency of nanobind.
* adds a PYTHON_BINDING_LIBRARY option to various CMake functions, such
as declare_mlir_python_extension, allowing users to select a Python
binding library.
* creates a fork of mlir/include/mlir/Bindings/Python/PybindAdaptors.h
named NanobindAdaptors.h. This plays the same role, using nanobind
instead of pybind11.
* splits CollectDiagnosticsToStringScope out of PybindAdaptors.h and
into a new header mlir/include/mlir/Bindings/Python/Diagnostics.h, since
it is code that is no way related to pybind11 or for that matter,
Python.
* changed the standalone Python extension example to have both pybind11
and nanobind variants.
* changed mlir/python/mlir/dialects/python_test.py to have both pybind11
and nanobind variants.
Notes:
* A slightly unfortunate thing that I needed to do in the CMake
integration was to use FindPython in addition to FindPython3, since
nanobind's CMake integration expects the Python_ names for variables.
Perhaps there's a better way to do this.
The current git_repository usage points to tags, which leads to warnings
that the build may not be reproducable due to not using a git sha.
The docs for
[git_repository](https://bazel.build/rules/lib/repo/git#git_repository)
recommend using `http_archive`, so switch to that instead. Also bump to
newer versions for these two repos.
Previously these targets were disabled, but with a relatively new
rules_python we can build these pointing at a hermetic python, which
allows us to build these safely. Users can still access the files
directly if they need to customize how these are built.
This tool doesn't work unless it's signed with the entitlements used
here. We should probably consider using the
macos_command_line_application rule from rules_apple which manages this
more flexibly for us, but for now this works. This uses apple_genrule as
opposed to genrule since the former encodes the Xcode environment info
into the action so it is correctly invalidated if that changes.
The only enabling configuration of this is irreproducible. Since
terminfo doesn't provide essential functionality, remove it so that all
external dependencies now follow the same config_setting pattern.
This should be an NFC for most setups and all CI setups.
Reviewed By: phosek, MaskRay
Differential Revision: https://reviews.llvm.org/D151006
Switches the library to use the zlib-ng implementation since the
original implementation is warning-incompatible with recent versions of clang.
Removes the wrapper logic for zlib in the bazel build and introduces new
logic to handle `LLVM_ENABLE_ZLIB`.
Removes the `BAZEL_LLVM_ZLIB_STRATEGY` environment variable and instead
introduces a boolean `--@llvm_zlib//:llvm_enable_zlib` flag which defaults
to true.
To migrate:
* The previous "external" strategy is the default. May be explicitly
enabled with `--@llvm_zlib//:llvm_enable_zlib=true`. For custom zlib
variants you can use the BUILD file at `third_party_build/zlib.BUILD`
as reference and adjust the `@llvm_zlib` archive in the `WORKSPACE`
directly.
* The previous "disable" strategy may be enabled with
`--@llvm_zlib//:llvm_enable_zlib=false`.
* The previous "system" strategy has been removed since it breaks
hermeticity. If you need the "system" setup, use the "external"
strategy and override the zlib dependency.
Addresses breakages of downstream projects using upstream clang and the
previously "external" zlib strategy (D141553).
Reviewed By: MaskRay, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D143320
Originally added in D128465. Used by `llvm:Support` and `lld:ELF`.
Enabled by default. Disable with `--@llvm_zstd//:llvm_enable_zstd=false`.
Reviewed By: MaskRay, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D143344
We used to have `pfm` built into exegesis, although since it's an external dependency we marked it as a manual target. Because of this we didn't have buildbot coverage and so we removed it in D134510 after we had a few breakages that weren't caught. This adds it back, but with three possible states similar to the story with `mpfr`, i.e. it can either be disabled, built from external sources (git/make), or use whatever `-lpfm` is installed on the system.
This change is modeled after D119547. Like that patch, the default is off (matching the status quo), but unlike that patch we don't enable it for CI because IIRC we don't have the package installed there, and building from source might be expensive. We could enable it later either after installing it on buildbot machines or by measuring build cost and deeming it OK.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D138470
This patch adds bazel tests for llvm-libc.
Some math tests rely on the `mpfr` library. This is controlled via the `--@llvm-project//libc:libc_math_mpfr` flag. It can take three values:
- `external` (default) will build `mpfr` and `gmp` from source.
- `system` will use the system installed `mpfr` library.
- `disable` will skip tests relying on `mpfr`.
Reviewed By: sivachandra, GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D119547
@GMNGeoffrey let me know it there's a better way to import MPFR and GMP for the purpose of testing libc math functions.
Differential Revision: https://reviews.llvm.org/D119547
RBE is currently broken due to the RBE container being too old and not supporting C++17.
The bots have already stopped using --config=rbe.
Differential Revision: https://reviews.llvm.org/D131722
Only require one intermediate repository instead of two.
Fewer parameters in llvm_config.
Second attempt of https://reviews.llvm.org/D107714, this time also updating `third_party_build` and `deps_impl` paths.
Reviewed By: GMNGeoffrey
Differential Revision: https://reviews.llvm.org/D108274
This breaks the rules for creating repository dependencies when invoked
from another workspace. See comment on https://reviews.llvm.org/D107714
This reverts commit 934f084ad42231d225bd0eee3342f4b5f7e1ce6e.
Differential Revision: https://reviews.llvm.org/D108245
I apparently left in the old digest when updating the version, so for my
local build Bazel just happily used the cached version, but anyone
attempting a fresth build would get a mismatch.
Differential Revision: https://reviews.llvm.org/D107010
