expat.h missing from dist/include/expat/ with parallel make

RESOLVED FIXED

Status

Firefox Build System
General
RESOLVED FIXED
12 years ago
3 months ago

People

(Reporter: Andrew Schultz, Assigned: cls)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

12 years ago
If I clobber build with -j2, the build often fails in parser/htmlparser/src because it pulls in /usr/include/expat.h.  That happens because expat.h is missing from dist/include/expat/.  expat_config.h is there, but not expat.h or expat_external.h.

The relevant chunk from my build log is:
gmake[5]: Entering directory `/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/parser/expat/lib'
Creating .deps
Creating ../../../dist/include/expat
/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/config/nsinstall -R -m 644 /home/andrew/tbox/SeaMonkey/Linux_2.4.
20-43.9.legacy_Depend/mozilla/parser/expat/lib/expat.h /home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/parser/expat/lib/
expat_external.h ../../../dist/include/expat
gmake[5]: Leaving directory `/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/parser/expat/lib'
/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/config/nsinstall -R -m 644 /home/andrew/tbox/SeaMonkey/Linux_2.4.
20-43.9.legacy_Depend/mozilla/parser/expat/expat_config.h ../../dist/include/expat
gmake[4]: Leaving directory `/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/parser/expat'
(Reporter)

Comment 1

12 years ago
er, I cut the build log off a bit too much.  The 2 lines before the chunk I included were:

gmake[4]: Entering directory `/home/andrew/tbox/SeaMonkey/Linux_2.4.20-43.9.legacy_Depend/mozilla/objdir/parser/expat'
Creating ../../dist/include/expat
(Assignee)

Comment 2

12 years ago
It looks like because we loop into subdirs before executing the local rules during the export phase, parser/expat/lib/Makefile is creating the directory first, then the directory is later being recreated by the parser/expat/Makefile .  This is similar to the problems we saw in bug 319460 .  We could try adding all of the directory-creating dependencies to the first export:: rule before LOOP_OVER_DIRS is called.  Try something like this:

-export:: $(SUBMAKEFILES) $(MAKE_DIRS)
+export:: $(SUBMAKEFILES) $(MAKE_DIRS) $(if $(EXPORTS)$(XPIDLSRCS)$(SDK_HEADERS)$(SDK_XPIDLSRCS),$(PUBLIC)) $(if $(SDK_HEADERS)$(SDK_XPIDLSRCS),$(SDK_PUBLIC)) $(if $(XPIDLSRCS),$(IDL_DIR)) $(if $(SDK_XPIDLSRCS),$(SDK_IDL_DIR))
(Reporter)

Comment 3

12 years ago
That worked 3 out of 3 times I tried from a complete clobber.  I couldn't get it to go bad just nuking dist/include/expat and re-exporting.
(Reporter)

Comment 4

12 years ago
Created attachment 217752 [details] [diff] [review]
cls' patch
Attachment #217752 - Flags: review?(benjamin)

Updated

12 years ago
Attachment #217752 - Flags: review?(benjamin) → review+
(Reporter)

Updated

12 years ago
Assignee: nobody → cls
(Reporter)

Comment 5

12 years ago
FIXED
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED

Updated

3 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.