On Tue, 8 Oct 2013 14:20:38 -0500 Andrew Deason <[email protected]> wrote:
> 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. I think the goal was to allow for external versions of `compile_et', so we do not need to have special options. > 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. Ok, thank you. Yes, it is serialized, but they do run twice, and the `rm' command is run both times; $(RM) -f cmd.h cmd_errors.c Btw, Is there a good reason to run `rm -f foo.c foo.h' before every `compile_et'? I assume this was done long ago to fix something? -- Michael Meffie <[email protected]> _______________________________________________ OpenAFS-devel mailing list [email protected] https://lists.openafs.org/mailman/listinfo/openafs-devel
