If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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

RESOLVED INVALID

Status

()

Core
Build Config
RESOLVED INVALID
14 years ago
5 months ago

People

(Reporter: dbaron, Unassigned)

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

14 years ago
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

13 years ago
Assignee: leaf → cmp
Product: Browser → Seamonkey

Comment 2

12 years ago
Mass reassign of open bugs for chase@mozilla.org to build@mozilla-org.bugs.
Assignee: chase → build

Comment 3

11 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
Component: Build Config → Build Config
Product: SeaMonkey → Core
QA Contact: build-config

Comment 4

5 months ago
All this has been rewritten and this bug is no longer valid.
Status: NEW → RESOLVED
Last Resolved: 5 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.