prelude_bazel file has undesirable behavior across external workspaces

[mmorearty]

Description of the problem / feature request / question:

The file tools/build_rules/prelude_bazel is automatically prepended to every BUILD file. But the behavior across external workspaces leads to undesirable behavior.

The tools/build_rules/prelude_bazel for the top-level workspace is prepended to every BUILD file of every workspace — both the top-level workspace and all pulled-in external workspaces. And if any external workspaces have their own tools/build_rules/prelude_bazel file, that file is ignored.

This leads to several problems:

1. Suppose I make a project called HelperLibrary that has its own tools/build_rules/prelude_bazel, and that file actually necessary in order to build HelperLibrary. But then ToplevelProject pulls in HelperLibrary as an external workspace, and uses it. In this case, HelperLibrary will not pull in tools/build_rules/prelude_bazel, so it will not compile correctly.
2. Conversely, suppose ToplevelProject has a tools/build_rules/prelude_bazel which has a load statement, e.g. load("//:toplevel_project.bzl", "toplevel_rule"). Then, when ToplevelProject pulls in HelperLibrary, HelperLibrary will fail to compile, because it can't find //:toplevel_project.bzl in its own workspace. There is a workaround for this issue: Use an @ sign, load("@//:toplevel_project.bzl", "toplevel_rule").

Not sure if #2 is a bug. But #1 certainly seems like a bug (or misfeature) to me.

If possible, provide a minimal example to reproduce the problem:

example.zip

project w1 imports project w2 as an external workspace.

If you cd into w2 and bazel build :all, it works.

But if you cd into w1 and bazel build :all, the part that is supposed to build the external workspace w2 fails.

Environment info

• Operating System: Mac, Linux
• Bazel version (output of bazel info release): 0.9.0

[ittaiz]

Did you look at #1673? Sounds very similar but I might be mistaken

…

On Wed, 20 Dec 2017 at 2:57 Mike Morearty ***@***.***> wrote: Description of the problem / feature request / question: The file tools/build_rules/prelude_bazel is automatically prepended to every BUILD file. But the behavior across external workspaces leads to undesirable behavior. The tools/build_rules/prelude_bazel for the top-level workspace is prepended to every BUILD file of every workspace — both the top-level workspace and all pulled-in external workspaces. And if any external workspaces have their own tools/build_rules/prelude_bazel file, that file is ignored. This leads to several problems: 1. Suppose I make a project called HelperLibrary that has its own tools/build_rules/prelude_bazel, and that file actually necessary in order to build HelperLibrary. But then ToplevelProject pulls in HelperLibrary as an external workspace, and uses it. In this case, HelperLibrary will not pull in tools/build_rules/prelude_bazel, so it will not compile correctly. 2. Conversely, suppose ToplevelProject has a tools/build_rules/prelude_bazel which has a load statement, e.g. load("//:toplevel_project.bzl", "toplevel_rule"). Then, when ToplevelProject pulls in HelperLibrary, HelperLibrary will fail to compile, because it can't find //:toplevel_project.bzl in its own workspace. There is a workaround for this issue: Use an @ sign, load("@//:toplevel_project.bzl", "toplevel_rule"). Not sure if #2 <#2> is a bug. But #1 <#1> certainly seems like a bug (or misfeature) to me. If possible, provide a minimal example to reproduce the problem: example.zip <https://github.com/bazelbuild/bazel/files/1573770/example.zip> project w1 imports project w2 as an external workspace. If you cd into w2 and bazel build :all, it works. But if you cd into w1 and bazel build :all, the part that is supposed to build the external workspace w2 fails. Environment info - Operating System: Mac, Linux - Bazel version (output of bazel info release): 0.9.0 — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#4330>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUIF7Zf_-zUf8hvgjtg_N3oOh7wyectks5tCFtsgaJpZM4RHwq-> .

[mmorearty]

You're right @ittaiz, same issue, thank you. And omg, that issue was fixed literally today! amazing timing :)