Closed
Bug 1071568
Opened 10 years ago
Closed 10 years ago
Metro builds break due to DIST_SUBDIR reassignment
Categories
(Firefox Build System :: General, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla35
People
(Reporter: jimm, Assigned: glandium)
References
Details
Attachments
(3 files)
7.50 KB,
text/plain
|
Details | |
1.84 KB,
patch
|
glandium
:
feedback-
|
Details | Diff | Splinter Review |
3.69 KB,
patch
|
mshal
:
review+
|
Details | Diff | Splinter Review |
Build mc with --enable-metro, a short while in you'll get: 0:43.34 Reticulating splines... 0:43.34 Traceback (most recent call last): 0:43.34 File "./config.status", line 935, in <module> 0:43.34 config_status(**args) 0:43.34 File "t:\Mozilla\metro\python\mozbuild\mozbuild\config_status.py", line 148, in config_status 0:43.34 summary = the_backend.consume(definitions) 0:43.34 File "t:\Mozilla\metro\python\mozbuild\mozbuild\backend\base.py", line 181, in consume 0:43.34 for obj in objs: 0:43.34 File "t:\Mozilla\metro\python\mozbuild\mozbuild\frontend\emitter.py", line 128, in emit 0:43.34 for out in output: 0:43.34 File "t:\Mozilla\metro\python\mozbuild\mozbuild\frontend\reader.py", line 833, in read_mozbuild 0:43.34 raise bre 0:43.34 mozbuild.frontend.reader.BuildReaderError: 0:43.34 ============================== 0:43.34 ERROR PROCESSING MOZBUILD FILE 0:43.34 ============================== 0:43.34 0:43.34 The error occurred while processing the following file: 0:43.34 0:43.34 t:/Mozilla/metro/browser/metro/shell/commandexecutehandler/moz.build 0:43.34 0:43.34 The error was triggered on line 15 of this file: 0:43.34 0:43.34 DIST_SUBDIR = 'dist/bin' 0:43.34 0:43.34 The underlying problem is an attempt to reassign a reserved UPPERCASE variable. 0:43.34 0:43.35 The reassigned variable causing the error is: 0:43.35 0:43.35 DIST_SUBDIR 0:43.35 0:43.35 Maybe you meant "+=" instead of "="?
Comment 1•10 years ago
|
||
Attachment #8501256 -
Flags: feedback?(mbrubeck)
Attachment #8501256 -
Flags: feedback?(jmathies)
Attachment #8501256 -
Flags: feedback?(bugs)
Comment 2•10 years ago
|
||
Comment on attachment 8501256 [details] [diff] [review] issue_dist_subdir.diff (I'm not familiar with this stuff at all.)
Attachment #8501256 -
Flags: feedback?(bugs)
Updated•10 years ago
|
Attachment #8501256 -
Flags: feedback?(mh+mozilla)
Attachment #8501256 -
Flags: feedback?(gps)
Assignee | ||
Comment 3•10 years ago
|
||
Comment on attachment 8501256 [details] [diff] [review] issue_dist_subdir.diff Review of attachment 8501256 [details] [diff] [review]: ----------------------------------------------------------------- This is most definitely not the right thing to do. Those overrides should just be fine, and since that's not the case, /that/ is the bug.
Attachment #8501256 -
Flags: feedback?(mh+mozilla)
Attachment #8501256 -
Flags: feedback?(mbrubeck)
Attachment #8501256 -
Flags: feedback?(jmathies)
Attachment #8501256 -
Flags: feedback?(gps)
Attachment #8501256 -
Flags: feedback+
Assignee | ||
Updated•10 years ago
|
Attachment #8501256 -
Flags: feedback+ → feedback-
Assignee | ||
Comment 5•10 years ago
|
||
It's not entirely clear passing down all the metadata makes sense. On the other hand, when creating the template execution sandbox, passing down exports does assign the value for the exported variable in that execution context. When that context is merged with the caller sandbox context, the exported variable is reassigned, even if the value is not modified. Then, if the caller sandbox itself reassigns the exported variable, it fails because calling a template already did it once, unexpectedly. Not passing down exported variables makes the template execution sandbox never set those exported variables, so that they are not merged back. The caller sandbox can then properly reassign the exported variable.
Attachment #8501474 -
Flags: review?(mshal)
Assignee | ||
Updated•10 years ago
|
Assignee: nobody → mh+mozilla
Status: NEW → ASSIGNED
Comment 6•10 years ago
|
||
Comment on attachment 8501474 [details] [diff] [review] Only pass down templates to the sandbox context when calling moz.build templates Look's like, this patch resolves current build issue...
Updated•10 years ago
|
Attachment #8501474 -
Flags: review?(mshal) → review+
Assignee | ||
Comment 7•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/964eb640d4a8
https://hg.mozilla.org/mozilla-central/rev/964eb640d4a8
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
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
•