search

dropbox / dbx_build_tools

Dropbox's Bazel rules and tools
Other
208 stars 36 forks source link

Make the steps from the README file work #4

Closed andni233 closed 4 years ago

andni233 commented 4 years ago

When used as an external dependency dbx_build_tools and its tools are unpacked in an "external" subdirectory. Following the steps in the README file, adding dbx_build_tools as an http_archive, it is unpacked in this way. This causes the itest-* tooling and others to not work as the scripts are looking in the wrong place for their runfiles.

Since dbx_build_tools is not always used as an external dependency, some logic to figure out where the runfiles directory can be found is required.

armooo commented 4 years ago

Do you have an example of when this change is needed?

As far as I can tell $RUNFILES/../dbx_build_tools and $RUNFILES/external/dbx_build_tools should give the same results unless --nolegacy_external_runfiles is enabled in which case $RUNFILES/external will not exists.

andni233 commented 4 years ago

Great observation! I am not able to reproduce this using the steps from the README.md file, modified to build from HEAD of dbx_build_tools.

To build on my system, I need 3d7a6f89e27c93edc8fdeed87a0e7908b66a069d that makes dbx_build_tools compatible with recent versions of glibc. To do so, I updated my WORKSPACE file to use the local_repository rule instead of http_archive.

Something like this:

local_repository(
    name = "dbx_build_tools",
    path = "/home/.../git/dbx_build_tools",
)

Apparently there is a difference in how http_archive and local_repository works. The local_repository rule seems to place the runfiles in a different location.

I think this change is needed if using dbx_build_tools included using the local_repository rule is a supported use case.