On Tue, 10 Sep 2013 11:02:54 -0400 Michael Meffie <[email protected]> wrote:
> Russ, thank you for the excellent information. Based on that automake > manual section, I've pushed a commit to gerrit to fix all the makefile > rules for compile_et in the tree. > > http://gerrit.openafs.org/#change,10237 This has come up again in 10325, since parallel builds are still sometimes failing. As far as I can tell, the linked approach in the automake manual doesn't (always) work, though I assume I am just missing something. Before I go any further I'd also just like to mention that just modifying our compile_et to just generate one file at a time would seem to be a pretty easy way to get rid of this whole problem. While I would like to understand what is happening here, I would like it _more_ if it just went away, so maybe that's a better way to go. But anyway: If anyone wants to follow along themselves, here's what I've been doing to get a reproducible scenario for fiddling around with this. I've taken the current head of 1.6.x (6c3adb6db781ef4b15d9336a63b40d3a79b11264), and ran regen, configure, and 'make cmd'. Then I go into src/cmd, 'make clean', and modify the Makefile so we have this: cmd_errors.c cmd.h: cmd_errors.et cmd.p.h $(RM) -f cmd.h cmd_errors.c echo sleeping ; sleep 1 ; echo done sleeping ${COMPILE_ET} -p ${srcdir} cmd_errors -h cmd touch cmd.h ls cmd.h: cmd_errors.c If I then 'make -j 2 all', it fails every time (make sure you 'make clean' between invocations). If you want to simplify things a bit for tracking what's going on (or reading 'make' debug output), you can change the 'all' target to: all: cmd_errors.o cmd_parse.o Which is a bit simpler, but still causes the failure. As far as I can tell, this is due to those two files depending on the two different outputs from compile_et; that is, one depends on cmd_errors.c, and one depends on cmd.h. If I switch both of them to depend on cmd_errors.c, the error does not occur. That's not _supposed_ to make a difference, since cmd.h depends on cmd_errors.c anyway, but apparently it does make a difference. Also, the compile_et commands are indeed serialized; they run twice, but not in parallel. What appears to be happening is that one make subprocess thinks that cmd.h does not exist when it does (i.e., it doesn't know that the compile_et rule generated it in addition to cmd_errors.c). So the compile_et rule is run again, though properly serialized; and a different make subprocess thinks that it has cmd_errors.c, so it invokes a cc command to use cmd_errors.c. I can provide make debug output if anyone wants it, but I believe the above instructions are easy enough for someone else to follow themselves, which is probably what you want to be doing if you want to look into it. -- Andrew Deason [email protected] _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
