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

[Michael Meffie]

On Tue, 8 Oct 2013 14:20:38 -0500
Andrew Deason <adeason@sinenomine.net> wrote:

> 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.

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 <mmeffie@sinenomine.net>