[OpenAFS-devel] Re: debian-linux-i386-builder issues

[Andrew Deason]

On Tue, 10 Sep 2013 11:02:54 -0400
Michael Meffie <mmeffie@sinenomine.net> 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
adeason@sinenomine.net