bazel icon indicating copy to clipboard operation
bazel copied to clipboard

`build` directory on macos causing glob to fail

Open michael-projectx opened this issue 1 year ago • 3 comments

Description of the bug:

I'm seeing the following failure:

ERROR: no such package '@@folly//': error globbing [**/*.h] op=FILES: /home/vscode/.cache/bazel/_bazel_vscode/d9fd8dd9485b3d1d1994c3846baefa35/external/folly/folly/build (No such file or directory)
ERROR: /workspaces/project-x/cpp_libs/logging/BUILD:130:11: no such package '@@folly//': error globbing [**/*.h] op=FILES: /home/vscode/.cache/bazel/_bazel_vscode/d9fd8dd9485b3d1d1994c3846baefa35/external/folly/folly/build (No such file or directory)

When I check the output of ls -al /home/vscode/.cache/bazel/_bazel_vscode/d9fd8dd9485b3d1d1994c3846baefa35/external/folly/folly/build

The directory does indeed exist:

total 8
drwxr-xr-x   4 vscode vscode  128 May 22 06:48 .
drwxr-xr-x 205 vscode vscode 6560 May 22 06:48 ..
-rwxrwxr-x   1 vscode vscode 2049 May 11 16:29 bootstrap-osx-homebrew.sh
-rwxrwxr-x   1 vscode vscode 3489 May 11 16:29 build-debs-ubuntu-18.04.sh

Attempting to add an exclude = ["folly/build/**"] to the glob rule doesn't seem to help.

My complete build rule is as follows:

cc_library(
    name = "header_only",
    hdrs = glob(["**/*.h"]),
    defines = {"FOLLY_NO_CONFIG": "1"},
    visibility = ["//visibility:public"],
    tags = ["no-clang-tidy"],
)

And the library is fetched using (in my WORKSPACE file):

http_archive(
    name = "folly",
    build_file = "@//:third_party/folly/build_file.bazel",
    sha256 = "f57f0d7726be7b0775fe717784e863866e207eff159b548a17f48d335d8e6504",
    url = "https://github.com/facebook/folly/releases/download/v2024.05.13.00/folly-v2024.05.13.00.tar.gz",
)

I'm on bazel version 7.0.2 on Mac OS

I have the same issue with another external dependency that also has a build folder. If I manually delete the build folder or rename it to something else, then the build succeeds.

It appears this has something to do with the case-insensitive filesystem on Mac OS because the same build works fine on Ubuntu. I've even attempted to create a new case-sensitive volume that I've symlinked my .cache/bazel directory to and the problem still persists.

Which category does this issue belong to?

External Dependency

What's the simplest, easiest way to reproduce this bug? Please provide a minimal example if possible.

No response

Which operating system are you running Bazel on?

mac os

What is the output of bazel info release?

release 7.0.2

If bazel info release returns development version or (@non-git), tell us how you built Bazel.

No response

What's the output of git remote get-url origin; git rev-parse HEAD ?

No response

Is this a regression? If yes, please try to identify the Bazel commit where the bug was introduced.

No response

Have you found anything relevant by searching the web?

No

Any other information, logs, or outputs that you want to share?

No response

michael-projectx avatar May 22 '24 07:05 michael-projectx

I'm having trouble to repro (assuming @//:third_party/folly/build_file.bazel the file containing the cc_library, and the build command is bazel build @folly//:header_only). Maybe something else in your workspace is required to trigger the issue (e.g. a .bazelrc file)? It might help to share the complete repro as a GitHub repository anyone can check out.

tjgq avatar May 22 '24 18:05 tjgq

Let me try to put something together

michael-projectx avatar May 22 '24 22:05 michael-projectx

Does this also happen to a build folder under your source tree instead of an external repo?

meteorcloudy avatar May 28 '24 15:05 meteorcloudy

I also run into this issue occasionally, although it seems to be non deterministic. I'm not 100% sure how to reproduce it.

@meteorcloudy, in my case it actually does throw the error for a folder in the source tree:

/srv/phantom/bazel/BUILD:117:10: no such package 'illusions': error globbing [inc/**] - [inc/build/**, inc/react/**] op=FILES: /srv/phantom/illusions/inc/phantom/scss/build (No such file or directory) and referenced by '//bazel:soar-tars'

Edit 9/9/2024: My going theory is that this might be caused by build folders which are globbed by bazel. I'll be trying to avoid globbing build folders, and renaming build folders to something else. Is bazel confusing build/ for BUILD? I'm running Docker on Mac, and Mac has a case insensitive filesystem. The repo is bind mounted, so I wonder if that's the issue (complete guess though)