git_repository target doesn't build, but build's on its own when local.

[mikewiacek]

Description of the problem / feature request:

https://github.com/VirusTotal/yara includes a WORKSPACE and bazel BUILD files. If you clone this repository, I can successfully bazel build :all without issue. However if another workspace references this repository via git_repository, it will not build successfully.

Included here is a complete walk through to reproduce...

[mike@filer 16:29:16 ~]$ bazel info release
Starting local Bazel server and connecting to it...
release 0.25.3

[mike@filer 16:33:32 ~]$ git clone https://github.com/VirusTotal/yara.git
Cloning into 'yara'...
remote: Enumerating objects: 14681, done.
remote: Total 14681 (delta 0), reused 0 (delta 0), pack-reused 14681
Receiving objects: 100% (14681/14681), 17.98 MiB | 6.80 MiB/s, done.
Resolving deltas: 100% (10568/10568), done.
Checking out files: 100% (268/268), done.
[mike@filer 16:33:49 ~]$ cd yara

[mike@filer 16:34:09 ~/yara]$ bazel build :libyara
INFO: Analyzed target //:libyara (11 packages loaded, 613 targets configured).
INFO: Found 1 target...
Target //:libyara up-to-date:
  bazel-bin/liblibyara.a
  bazel-bin/liblibyara.so
INFO: Elapsed time: 6.241s, Critical Path: 1.81s
INFO: 301 processes: 301 linux-sandbox.
INFO: Build completed successfully, 304 total actions
[mike@filer 16:34:18 ~/yara]$

All looks good? Now let's try this as a remote git repository in a clean workspace.

[mike@filer 16:35:21 ~]$ mkdir new_workspace
[mike@filer 16:35:43 ~/new_workspace]$ vi WORKSPACE

WORKSPACE contains the following...

load("@bazel_tools//tools/build_defs/repo:git.bzl", "git_repository")

git_repository(
    name = "boringssl",
    commit = "863837047be74b20f59369b5256c39ad00f015b3",
    remote = "https://boringssl.googlesource.com/boringssl",
)

git_repository(
    name = "yara_ext",
    commit = "305ba7afa48d3fced5dfd324789d5c795bcc47b2",
    remote = "https://github.com/VirusTotal/yara",
)

[mike@filer 16:39:08 ~/new_workspace]$ bazel build @yara_ext//:all
INFO: Analyzed 5 targets (0 packages loaded, 0 targets configured).
INFO: Found 5 targets...
ERROR: /tmp/bazel_out_mike/d40b1fcf1140a86564738a571d7f7f49/external/yara_ext/BUILD.bazel:108:1: C++ compilation of rule '@yara_ext//:libyara' failed (Exit 1) gcc failed: error executing command /usr/bin/gcc -U_FORTIFY_SOURCE -fstack-protector -Wall -Wunused-but-set-parameter -Wno-free-nonheap-object -fno-omit-frame-pointer -MD -MF ... (remaining 61 argument(s) skipped)

Use --sandbox_debug to see verbose messages from the sandbox
In file included from hex_lexer.l:56:0:
external/yara_ext/libyara/include/yara/hex_lexer.h:79:10: fatal error: hex_grammar.h: No such file or directory
 #include <hex_grammar.h>
          ^~~~~~~~~~~~~~~
compilation terminated.
INFO: Elapsed time: 0.667s, Critical Path: 0.23s
INFO: 19 processes: 19 linux-sandbox.
FAILED: Build did NOT complete successfully

[mikewiacek]

This might be a bug with the build rules in yara, it looks like the cc_library target for yara needs some extract includes = [...] paths set.

I'll leave this bug open though, just in case there is something weird with bazel here as it's unclear if it should have compiled at all in the first place.

[laurentlb]

I'm surprised that it doesn't find hex_grammar.h. It might be an issue with cc_ rules, but I haven't investigated.

[scentini]

This is a known issue with the cc_rules, we're working on it.
The reason why this happens is because currently there is no other way to specify nontransitive include paths in a cc_library except through the copts attribute.

The libryara actually passes the include directive for the private headers here.
However, when building it as an external repository, the headers end up in a slightly different location, thus the "-Ilibyara" doesn't work, see #4463.

This will be fixed as part of #6790.

[meisterT]

This is still an issue with current Bazel.

[github-actions]

Thank you for contributing to the Bazel repository! This issue has been marked as stale since it has not had any activity in the last 2+ years. It will be closed in the next 14 days unless any other activity occurs or one of the following labels is added: "not stale", "awaiting-bazeler". Please reach out to the triage team (@bazelbuild/triage) if you think this issue is still relevant or you are interested in getting the issue resolved.

[github-actions]

This issue has been automatically closed due to inactivity. If you're still interested in pursuing this, please reach out to the triage team (@bazelbuild/triage). Thanks!