Closed Bug 216419 Opened 21 years ago Closed 7 years ago

build/autoconf/acoutput-fast.pl creates directories when Makefile.in not present

Categories

(Firefox Build System :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: dbaron, Unassigned)

Details

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.
Assignee: mozbugs-build → leaf
Assignee: leaf → cmp
Product: Browser → Seamonkey
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Mass re-assign of bugs that aren't on the build team radar, so bugs assigned to build@mozilla-org.bugs reflects reality.

If there is a bug you really think we need to be looking at, please *email* build@mozilla.org with a bug number and explanation.
Assignee: build → nobody
Product: SeaMonkey → Core
QA Contact: build-config
All this has been rewritten and this bug is no longer valid.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.