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)
Firefox Build System
General
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
Updated•20 years ago
|
Assignee: leaf → cmp
Updated•20 years ago
|
Product: Browser → Seamonkey
Comment 2•18 years ago
|
||
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build
Comment 3•18 years ago
|
||
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
Updated•15 years ago
|
Product: SeaMonkey → Core
QA Contact: build-config
Comment 4•7 years ago
|
||
All this has been rewritten and this bug is no longer valid.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Updated•6 years ago
|
Product: Core → Firefox Build System
You need to log in
before you can comment on or make changes to this bug.
Description
•