Closed Bug 800847 Opened 8 years ago Closed 8 years ago doesn't create working dependencies of Makefiles on gyp files


(Core :: WebRTC, defect)

Not set



Tracking Status
firefox18 --- fixed
firefox19 --- fixed


(Reporter: jesup, Assigned: jesup)



(Whiteboard: [qa-])


(1 file)

[I could swear there's an open bug on this, but can't find it.  This appears to be causing frequent need to clobber inbound.  It's unclear why, as gyp files shouldn't be changing there; it may be somehow related to the dep builds or some incomplete clobbers after a gyp change.]

Dependencies of Makefiles on gypfiles is broken; you typically (during export) see:

    ProcessConditionsInDict(the_dict, phase, variables, build_file)
  File "/builds/slave/m-in-osx64/build/media/webrtc/trunk/tools/gyp/pylib/gyp/", line 885, in ProcessConditionsInDict
    if eval(ast_code, {'__builtins__': None}, variables):
  File "<string>", line 1, in <module>
NameError: name 'use_system_libvpx' is not defined while evaluating condition 'use_system_libvpx==0' in /builds/slave/m-in-osx64/build/media/webrtc/trunk/src/modules/video_coding/codecs/vp8/vp8.gyp while loading dependencies of /builds/slave/m-in-osx64/build/media/webrtc/trunk/src/modules/modules.gyp while loading dependencies of /builds/slave/m-in-osx64/build/media/webrtc/trunk/peerconnection.gyp while trying to load /builds/slave/m-in-osx64/build/media/webrtc/trunk/peerconnection.gyp
Note: includes temporary fix for bug 798969 from the patch there
Comment on attachment 670735 [details] [diff] [review]
Correctly regenerate Makefiles from gyp files

Ok, it may not be the only problem (or maybe it is), but a primary issue is that generated by is missing options specified in, in particular --include ${srcdir}/media/webrtc/webrtc_config.gypi

This passes the --include through a -D value as well, and thus also ensures it survives in the file and doesn't disappear when regenerates the makefiles (including itself).

In testing it appears to both correctly trigger re-runs of gyp, but also doesn't change after a re-run.

As mentioned, this has the hacky solution for the path issue to find gyp (bug 798969)
Attachment #670735 - Flags: review?(ted.mielczarek)
I'd also add a comment to that some changes to gyp invocation will require modifying as well.
Duplicate of this bug: 800628
Comment on attachment 670735 [details] [diff] [review]
Correctly regenerate Makefiles from gyp files

Review of attachment 670735 [details] [diff] [review]:

This is gross, but let's unbreak things. Maybe we can add that info to gyp and get it upstreamed to do this a clean way.
Attachment #670735 - Flags: review?(ted.mielczarek) → review+
.mozconfig -  

hg log -l 5 -  

Errors after a clobber -

Using Xcode 4.5.1 with Command Line tools installed on Mac OS X 10.7.5
Assignee: nobody → rjesup
Closed: 8 years ago
Flags: in-testsuite-
Resolution: --- → FIXED
Target Milestone: --- → mozilla19
Whiteboard: [qa-]
ted: should we uplift this to Aurora to keep (re)builds there sane?
Comment on attachment 670735 [details] [diff] [review]
Correctly regenerate Makefiles from gyp files

[Approval Request Comment]
Bug caused by (feature/regressing bug #): webrtc
User impact if declined: Touching gyp files or anything else that triggers a gyp dependency build (and something on builders occasionally does without a gyp change it appears) will leave the build busted until a clobber is done.  This was causing frequent clobbers on m-i/m-c, and had messed up some of the windows buildsers.
Testing completed (on m-c, etc.): Stable on m-c since last Friday
Risk to taking this patch (and alternatives if risky): No risk to build, only an developer/infrastructure issue.
String or UUID changes made by this patch: None
Attachment #670735 - Flags: approval-mozilla-aurora?
Yes, I think so.
Attachment #670735 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.