The fact that build/autoconf/acoutput-fast.pl creates a directory even when the Makefile.in isn't present means that people checking in in the wrong order (landing allmakefiles.sh changes before checking in the new directory) can cause a tinderbox doing a srcdir build to get merge conflicts. The current directory creation mechanism there is documented to be faster, but I wonder if the performance penalty is worth having to kick tinderboxes when people check in in the wrong order. Correspondance about the bustage follows (I wrote the unquoted text): On Saturday 2003-08-16 14:13 -0700, Brian Ryner wrote: > Pierre Chanial wrote: > >for some reason, linux tree went red. The reason is that you need to check new files in before adding them to the build. Since the build in question was a srcdir build, your allmakefiles.sh changes caused the toolkit/components/printing directory to be created in the cycle *before* the new files were pulled. Then when CVS pulled the files, it created the printing directory just fine, but it didn't add the appropriate directory line to toolkit/components/CVS/Entries, which then makes it think that it doesn't have any cvs files for that directory, leading to the error you mention. It was reasonably easy to verify (as I just did) that this chain of events will cause the problem that occurred. It's perhaps worth filing a bug on the code that uses the makefile list in allmakefiles.sh so it doesn't generate directories for makefiles that it can't create. (It may be worth filing a bug on cvs as well, although the bug would be that cvs should have shown conflicts a cycle earlier than it actually did.) In any case, all that should need to be deleted is toolkit/components/printing -- but not at a point between the mozilla/toolkit pull and the beginning of the build, when allmakefiles.sh is used.
Mass reassign of Build/Config bugs to Leaf.
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to firstname.lastname@example.org reflects reality. If there is a bug you really think we need to be looking at, please *email* email@example.com with a bug number and explanation.
All this has been rewritten and this bug is no longer valid.