Recommended way to install files in different directories ?

[hzeller]

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 ?

[bttk]

I had this functionality in mind for some time now, as seen in Features in README.md:

• [ ] Installs a directory tree.
• [ ] Renames installed files

Focusing on rule usability, I think the right approach is to use a label_keyed_string_dict. Usage could look like this:

# file /install/BUILD

# Run in workspace root:
#   bazel run install -- -s /usr/local
# Run anywhere in workspace
#   bazel run //install -- -s /usr/local
installer(
  name = "install",
  paths = {
    "//src/foo": "/bin/",  # cc_binary
    "//src/include:headers": "/include/", # filegroup
    "//doc:foobar.htm": "/share/foo/foobar.html", # file (renamed, because path doesn't end in "/")
  },
)

The issue I'm having here, is that this hits the limits of what can be accomplished with a bash template, so I'm considering a migration to Go for portability.

What do you think?

[hzeller]

I am not sure if pulling in go would be a good idea from a dependency perspective - it makes it harder to get a functioning build-environment.

But wouldn't all these string-mainpulations not be possible in starlark ? Then we can invoke the system-specific install tool with all the strings already prepared in bazel.

[bttk]

The build environment is supplied by bazel (in the WORKSPACE file) - you don't need golang installed on your system for bazel to build Go code. I'm considering Python as an alternative to Go, but I still leaning toward the latter.

[hzeller]

You still need to be able to have a machine that allows to build golang. So now the build-envioronment would depend on ∩ (machines-that-run-java, machines-that-run-golang)