Re: 2.15.15 doesn't build on Mageia

[David Kastrup]

Julien Rioux <address@hidden> writes:

> One should be careful not to take such guesses as postulates, as it
> seems I did. I don't think we want someone (the poster, or a good
> samaritan willing to spend some of their free time happily fixing
> things up in the lilypond build system) to spend time tracking down an
> evil make rule with side effects that removes a file midway through
> the build when, heck, we don't even know, for one, if the file was
> ever created in the first place. Imagine that, that's a lot of wasted
> time. Much better would be to establish the cause first. That's all.

I quote from your _own_ analysis:

>> The dependency is correct (it includes $(outdir)/%.texi which
>> evaluates to out/contributor.texi) so `make' knows that it needs this
>> file. Also, `make' seems to think that the file exists, but `makeinfo'
>> reports that it does not.

make does not think a file exists without a reason.  Either it had a
rule for creating it, in which case it is quite unlikely that the
actions intended to create it failed without an exit status indicating
this failure, or the rule was successful creating it, but it disappeared
again before its time.

You have been chastising me for even mentioning the implications of
parallel make.  So you would appear to be ready to bet at least 4:1 that
my guess was wrong, or your behavior would have been strange, to say the
least.  I am easily willing to bet you €100 against €200 of yours that
it _is_ a problem of parallel make stomping over the generated file in
parallel while the other job is confident in assuming that the file
still exists.

That's not a particularly hard bet to make, actually.  Here are the
pointers:
a) other people don't see that problem with the same source, so it is
not deterministic.  There is nothing nondeterministic about a
non-parallel make run.
b) in fact, other people _have_ seen that problem with Lilypond and have
reported it for years, each time mentioning that it did occur
sporadically, in connection with parallel make, and could be "fixed" by
repeating the make run.  The problem has already been _analyzed_ on the
list.

How do you get nondeterminism without parallel jobs?  Difficult.  It is
possible to write Make rules that fail in progressing places.  But
nondeterministically, so that one person sees the failures, and the next
doesn't?

-- 
David Kastrup