Multiple genrules should allow outputs with the same name

[shs96c]

Description of the problem / feature request:

The given build file does not allow bazel to run as it complains about conflicting outputs.

genrule(
  name = "one",
  outs = ["bar"],
  srcs = ["foo"],
  cmd = "cp $(location foo) $@")

genrule(
  name = "two",
  outs = ["bar"],
  srcs = ["baz"],
  cmd = "cp $(location baz) $@")

While this is a pathological case, it's easy to reach this point accidentally by invoking macros. It seems like an unnecessary constraint.

Feature requests: what underlying problem are you trying to solve with this feature?

It should be possible for the outputs of different rules (particularly genrules) to have the same name. Buck allows this by creating an output directory named after the rule (buck-out/gen/one and buck-out/gen/two in this case) rather than the package as bazel does (bazel-genfiles/ in this case).

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

See the build file above.

What operating system are you running Bazel on?

OS X, but this is reproducible everywhere

What's the output of bazel info release?

release 0.22.0

[gregestren]

Thanks for the report, Simon. This is close to some stuff I"m working on.

For many of Bazel's outputs I think we have options. But for something like the above example it isn't quite as simple. For example, what should

genrule(
    name = "consumer",
    srcs = ["//mypackage:bar"],
    outs = ["gg2.out"],
    cmd = "cat $< > $@")

do?

In others words, genrule outs use the same label naming logic as any rule. So by definition //mypackage:bar must match outs = ["bar"].

What macros are bothering you?

[shs96c]

Apologies for the very slow reply. In the example you gave, I would expect the srcs to list either //:one or //:two, which unambiguously declares which output should be used. I think it's perfectly valid for bazel to stop the build if there's any ambiguity in the build graph.

[gregestren]

Sure that makes sense. On what criteria would you want to disambiguate for this example?

So if I do $ bazel build //:gg2.out, I haven't provided enough information to determine if //:one or //:two should invoke.

[shs96c]

I think it's perfectly valid for bazel to stop the build if there's any ambiguity.

In the case you've given, I'd expect bazel to request the user to select which rule they want the output of (obviously, this would mean editing the build file --- I don't envision an interactive process!). That is, the person constructing the build file (or the command line) is responsible for ensuring that the build is unambiguous.

From my understanding of bazel, this can be done as we build the action graph. We wouldn't need to perform a full build in order to check this.

[gregestren]

For command line disambiguation, I think select() covers similar territory.

But it's an interesting idea to consider. I'd think of this as something like "annotated labels".

[shs96c]

I think the disambiguation piece is interesting, but the important thing is the two outputs with the same file name :)

[laurentlb]

It should be possible for the outputs of different rules (particularly genrules) to have the same name. Buck allows this by creating an output directory named after the rule (buck-out/gen/one and buck-out/gen/two in this case) rather than the package as bazel does (bazel-genfiles/ in this case).

So the workaround is to create the genrules in two subpackages?

[aiuto]

I'm closing this because where are reasonable workarounds and implementing it is expensive. There is little chance our team will ever implement it.