| commit | 4afd0b3ccd8379af11f67f7ddff525fd1a9c5834 | [log] [tgz] |
|---|---|---|
| author | elsk <[email protected]> | Wed Aug 28 12:14:02 2024 -0700 |
| committer | GitHub <[email protected]> | Wed Aug 28 15:14:02 2024 -0400 |
| tree | b0312913f3ba8cb16c1894b9ab29a0611c4a75e4 | |
| parent | 412c8fe9558f6bed4e1cfdc805d03dfc69c92ccf [diff] |
pkg_install: Add destdir attr & read rel paths. (#886) Implementation notes: Relative paths are interpreted against BUILD_WORKSPACE_DIRECTORY, not BUILD_WORKING_DIRECTORY. This is for the following reasons: The TODO tag explicitly convey the intention of using BUILD_WORKSPACE_DIRECTORY for relative paths. If destdir is specified in the attribute of the pkg_install() target, interpreting it against BUILD_WORKSPACE_DIRECTORY is much stabler. That is, no matter where your current cwd is, the destdir attribute always refers to a path relative to the workspace root. For example: ``` pkg_install(name = "my_pkg_install", destdir = "out/dest") ``` ``` cd <workspace_root>/<some_subdir> bazel run //:my_pkg_install ``` This clearly conveys that the default destdir is <workspace_root>/out/dest regardless of where the user runs the command. The cost is that the --destdir command line argument becomes trickier to understand. For example, if one is not familiar with pkg_install, and below the workspace root they run: ``` cd <workspace_root>/out bazel run //:my_pkg_install -- --destdir dest ``` They may expect the destdir to be set to <workspace_root>/out/dest; but it is in fact `<workspace_root>/dest`. We could also interpret the target attribute & the command line argument separately (e.g. pkg_install(destdir_against_workspace)), but honestly I think that's even more confusing when they interpret relative paths differently. Please let me know if this is preferred by the maintainers. Co-authored-by: HONG Yifan <[email protected]>
Bazel rules for building tar, zip, deb, and rpm for packages.
For the latest version, see Releases (with WORKSPACE setup) / Documentation
Use [email protected] for discussion.
CI: 
As of Bazel 4.x, Bazel uses this rule set for packaging its distribution. Bazel still contains a limited version of pkg_tar but its feature set is frozen. Any new capabilities will be added here.
Sample, but see releases for the current release.
load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
http_archive(
name = "rules_pkg",
urls = [
"https://mirror.bazel.build/github.com/bazelbuild/rules_pkg/releases/download/0.9.1/rules_pkg-0.9.1.tar.gz",
"https://github.com/bazelbuild/rules_pkg/releases/download/0.9.1/rules_pkg-0.9.1.tar.gz",
],
sha256 = "8f9ee2dc10c1ae514ee599a8b42ed99fa262b757058f65ad3c384289ff70c4b8",
)
load("@rules_pkg//:deps.bzl", "rules_pkg_dependencies")
rules_pkg_dependencies()
To use pkg_rpm(), you must provide a copy of rpmbuild. You can use the system installed rpmbuild with this stanza.
load("@rules_pkg//toolchains/rpm:rpmbuild_configure.bzl", "find_system_rpmbuild")
find_system_rpmbuild(
name = "rules_pkg_rpmbuild",
verbose = False,
)
bazel_dep(name = "rules_pkg", version = "0.0.10")
To use pkg_rpm(), you must provide a copy of rpmbuild. You can use the system installed rpmbuild with this stanza.
find_rpm = use_extension("//toolchains/rpm:rpmbuild_configure.bzl", "find_system_rpmbuild_bzlmod")
use_repo(find_rpm, "rules_pkg_rpmbuild")
register_toolchains("@rules_pkg_rpmbuild//:all")
We hold an engineering status meeting on the first Monday of every month at 10am USA East coast time. Add to calendar / meeting notes