google / bazel_rules_install

Bazel rules for installing build results. Similar to `make install`.

Install rules for Bazel

This is not an officially supported Google product.

Overview

This project aims at making it easy to install Bazel projects on local workstations.

Features

• installer rule:
  • Installs given file(s) in a directory.
  • Installs a directory tree.
  • Prevents accidental installation of debug builds.
  • Renames installed files.
  • Selects a sensible default install prefix.
  • When needed asks for write access (sudo).
• OS support:
  • Linux
  • macOS
  • Windows

Rules

• installer

Setup

1. In the WORKSPACE file of your Bazel project add the following:

   load("@bazel_tools//tools/build_defs/repo:http.bzl", "http_archive")
   
   http_archive(
       name = "com_github_google_rules_install",
       urls = ["https://github.com/google/bazel_rules_install/releases/download/0.3/bazel_rules_install-0.3.tar.gz"],
       sha256 = "ea2a9f94fed090859589ac851af3a1c6034c5f333804f044f8f094257c33bdb3",
       strip_prefix = "bazel_rules_install-0.3",
   )
   
   load("@com_github_google_rules_install//:deps.bzl", "install_rules_dependencies")
   
   install_rules_dependencies()
   
   load("@com_github_google_rules_install//:setup.bzl", "install_rules_setup")
   
   install_rules_setup()

2. In the BUILD file of the package where you want to add an installer add the following:

   # In file src/path/to/pkg/BUILD:
   
   load("@com_github_google_rules_install//installer:def.bzl", "installer")
   
   installer(
       name = "install_foo",
       data = [":foo"],
   )

Usage

Run the installer using bazel run. The following example installs foo in ~/bin:

bazel run //src/path/to/pkg:install_foo -- ~/bin

sudo

If you need to use sudo to install a file in a system directory:

• Do not run sudo bazel.
• Instead pass flag -s to the installer.

bazel run //src/path/to/pkg:install_foo -- -s /usr/local/bin

Debug builds

By default installer uses targets built with -c opt. To disable this override of a command line flag use compilation_mode = "" attribute:

installer(
    name = "install_foo",
    compilation_mode = "",
    data = [":foo"],
)

Alternatively you can force a debug build:

installer(
    name = "install_foo_dbg",
    compilation_mode = "dbg",
    data = [":foo"],
)

See also

• Examples

bazel_rules_install's Issues

Recommended way to install files in different directories ?

A common use is to install various artifacts in places in a $(PREFIX) location. So e.g. with PRFIX=/usr/local, we'd like to install, e.g.

• foo_binary -> /usr/local/bin
• foo_headers -> /usr/local/include/foo
• foo_lib -> /usr/local/lib/
• foo_doc -> /usr/local/share/foo/doc
• manpages -> /usr/local/man/

Right now, the install task directly installs everything in one directory, however the above use-case is essentially the next step. Short of manually lining up a bunch of separate install() rules, is there a recommended way, or possibly planned future way, to accomodate this situation ?

MacOS: install has different options there

Version: bazel_rules_install tag 0.4. Not sure what MacOS exactly, uname spits out something like Darwin Kernel Version 19.6.0

When compiling a project that compiles with bazel on MacOS (in my case: verible), the install procedure is not working, possibly because the install on MacOS is a BSD install, not GNU install.

In particular it seems to stumble upon the -- separator between options and arguments.

bazel run -c opt :install -- ~/bin
#.... 
install: illegal option -- -
usage: install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 file2
       install [-bCcpSsv] [-B suffix] [-f flags] [-g group] [-m mode]
               [-o owner] file1 ... fileN directory
       install -d [-v] [-g group] [-m mode] [-o owner] directory ...

Looking at the bazel-bin/_install_gen.sh (which I suspect is the one invoked) contains the following snippet, which is possibly the culprit:

  $sudo install --mode="${target_mode}" \
    -T -- "${source}" "${target_dir}/${target_name}"

I know that MacOS is still on the TODO list, but I hope this actual use-case might help raise the awareness (we just recently were able to get the project to compile on MacOS, so this would be the final stumbling block).

Maybe as a first step, the -- could only be emitted if the target looks like it would be in danger to be interpreted as option ? Given that binaries rarely (if ever) start with dash, this should fix the typical use-case.

Error, not a valid absolute pattern

bazel build -c opt //:install_foo -- ~/test
but get error message "not a valid absolute pattern (absolute target patterns must start with exactly two slashes): '/home/xxx/test'...."
Confused about this, and how could resolve it?

Clarification: what happens when running as root ?

For installing binaries in system directories, one has to run the installer as root

sudo bazel run :install -c opt /usr/local/bin

Bazel does all kinds of internal caching of object files and writes status files etc. Will this mess up the ~/.cache/bazel files, or will this 'just work', as then bazel would create these artifacts in ~root/.cache/bazel. I suspect the latter; and while this is duplicate of build work as different user, this is probably an acceptable solution for now.

(in a typical make situation, one would run make to build the artifacts, then sudo make install to just do the copying. Bazel is a lot more complex, so I want to make sure that this will work as intended).

OR: is it currently not recommended running bazel as root and wait for the When needed asks for write access checkbox to be implemented ?

Either way, it is probably good to clarify that in the README.

Support Bzlmod

Docs: https://bazel.build/external/overview#bzlmod

Security Vulnerabilities reported on java minimal images

We are seeing multiple Critical and High severity vulnerabilities in the java images, in both version 8 & 11.

They appear to be in glibc, libpng & libjpeg-turbo packages. Below is the image scanning report from Docker hub.

An online search reveals that there are newer versions of these packages available. But I am not sure how to update the packages inside the base images, or if there is an alternative to addressing these security findings.

installer installs only the FilesToRunProvider main executable and ignores other files

Currently, install seems to not work around this line:
https://github.com/google/bazel_rules_install/blob/master/installer/def.bzl#L33

there is a short_path accessed on the file object, but apparently that file is a broken object.
This is with bazel 2.2.0, trying to compile https://github.com/google/verible

ERROR: /tmp/verible/BUILD:15:1: in _gen_installer rule //:_install_gen:
Traceback (most recent call last):
File "/tmp/verible/BUILD", line 15
_gen_installer(name = '_install_gen')
File "/home/hzeller/.cache/bazel/_bazel_hzeller/738e401e7245498e1452e2a408c408c7/external/com_github_google_rules_install/installer/def.bzl", line 33, in _gen_install_binary_impl
sources.append(file.short_path)
File "/home/hzeller/.cache/bazel/_bazel_hzeller/738e401e7245498e1452e2a408c408c7/external/com_github_google_rules_install/installer/def.bzl", line 33, in sources.append
file.short_path
'NoneType' value has no field or method 'short_path'

Alias target not installed. Expected to be symbolic link or copy depending on platform

An alias rule
https://docs.bazel.build/versions/3.2.0/be/general.html#alias
gives a different name to an existing thing.

I'd like to use this in verible to phase out legacy binary names and move them to new names (to implement chipsalliance/verible#169 ).

But simply declaring this in bazel:

alias(
   name = "old_binary_name",
   actual = ":new_binary_name"
)

and then using the old_binary_name alias name in an bazel_rules_install installer() target will not install anything (but will also not complain); I suppose because the alias is actually just an internal name within bazel, but actually never shows up as tangible object.

For installation: My proposal would be to interpret the alias information and create either a symbolic link or a copy, depending on the installation platform.

(Of course, I could implement the legacy-names with a little shell-script which then exec's the new location etc., but it would be less platform agnostic. Using 'alias' is the exact abstraction that conveys the intent much better and the install target can use the additional context to do the right thing on the target platform - symbolic link or copy)

Support installer on Windows

New owner needed

I can no longer do any maintenance on this repo.

FR: installer automatically reruns itself with sudo when needed

FR: Make it possible to install a file under a different name

Example:
$ bazel build -c opt //install:buildifier ~/bin would install buildifier as ~/bin/buildifier

Create a flag which lets the user install buildifier as ~/bin/bazelfier