Julien Rioux <jri...@physics.utoronto.ca> 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 _______________________________________________ bug-lilypond mailing list bug-lilypond@gnu.org https://lists.gnu.org/mailman/listinfo/bug-lilypond
