`plz build` hangs when subincluding a build def from the package that defines and subincludes the build def
MWE:
# pkg/constant.build_defs:
CONSTANT = "constant"
# pkg/BUILD:
export_file(
name = "constant",
src = "constant.build_defs",
visibility = ["PUBLIC"],
)
subinclude(":constant")
genrule(
name = "output",
outs = ["out"],
cmd = "echo $CONSTANT > $OUTS",
env = {
"CONSTANT": CONSTANT,
},
)
# pkg2/BUILD:
subinclude("//pkg:constant")
genrule(
name = "output",
outs = ["out"],
cmd = "echo $CONSTANT > $OUTS",
env = {
"CONSTANT": CONSTANT,
},
)
//pkg:output builds fine:
$ plz build //pkg:output
Build finished; total time 50ms, incrementality 100.0%. Outputs:
//pkg:output:
plz-out/gen/pkg/out
$ cat $(plz query output //pkg:output)
constant
but building //pkg2:output hangs indefinitely. Looking at the output of -v debug, it hangs after the cycle detection has finished:
13:43:25.904 INFO: Total cache size: 11 GB
13:43:30.369 DEBUG: Running cycle detection...
13:43:30.369 DEBUG: Cycle detection complete, no cycles found
My best guess at what's happening here is that subincluding //pkg:constant from //pkg2 causes Please to load pkg/BUILD, which then has no idea what to do when it encounters the same subinclude that it's already been asked to load. In retrospect this is a silly thing to do, but I was surprised that the latter caused Please to hang indefinitely and that the former worked at all - in fact it was the former working that gave me hope that the latter might also work...
I think I've seen this before. From memory:
- pkg2 is promising to parse
pkgwhen it queues it up for sub-include - The subinclude in pkg is naively blocking waiting for
pkgto parse but is stuck because pkg2 promised to parse it, but that parse is this parse. - the subinclude blocks for ever because they're now both waiting on each-other to parse the package
Might be a simple fix where we don't wait for the package to parse is the package is the current package. Let me see if I can test that out.
This issue has been automatically marked as stale because it has not had any recent activity in the past 90 days. It will be closed if no further activity occurs. If you require additional support, please reply to this message. Thank you for your contributions.
This issue has been automatically marked as stale because it has not had any recent activity in the past 90 days. It will be closed if no further activity occurs. If you require additional support, please reply to this message. Thank you for your contributions.
Unmarking as stale since this bug still exists, although #2523 will fix it.