Issue metadata
Sign in to add a comment
|
GN: changes to build_overrides constantly break downstream projects |
||||||||||||||||||||||||
Issue descriptionV8 stand-alone automatically updates //build as a dependency with an auto-roller. This approach breaks now daily because changes in //build depend on new identifiers in build_overrides and creates disturbing porting work. Examples: https://codereview.chromium.org/2267753002 broke https://codereview.chromium.org/2289063002 https://codereview.chromium.org/2293853002 broke https://codereview.chromium.org/2293333002/ Suggestions: 1) Only read the values from build_overrides guarded by a "defined" check and use meaningful defaults if undefined. 2) Make folks land dependent CLs in subrepos first (not a very local approach). 3) Change the build_override mechanism so that it is truly "override". I.e. allow optionally overriding a given default. Currently we have to specify a (possibly different) default everywhere. 1 and 2 would be rather social attempts, i.e. only lgtm CLs that take care of this.
,
Sep 1 2016
2 times in 2 days :) This is only a dup IMO if we change the mechanism. The suggestions 1 and 2 could be taken care of independently, but it's merely a process thing that reviewers and owners should remember, i.e. no action required here. I also thought about if it's possible to run gn on the chromium side in an as-if-it's-v8-stand-alone kind of way. Just running gn only takes milliseconds, the problem is the current directory arrangement of the deps... I wonder if we could simply simulate the v8 stand-alone layout with a set of hard-links on linux...
,
Sep 1 2016
Yes, the intent is to change the mechanism, because the current mechanism is clearly both awkward and flawed. I'm not sure how running gn on the chromium side would help things, unless you're hoping that we would catch breakages? I don't think the breakages were a surprise, since every time you add something to build_overrides things'll break (or at least need to be manually rolled).
,
Sep 2 2016
Checking it on the chromium-side would move the manual work-load from the subrepo maintainers to the feature developer (i.e. the dev that adds new things to build_overrides). But I guess this doesn't scale well - just as little as the current approach.
,
Sep 9 2016
Another breakage: https://codereview.chromium.org/2319273002/ |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by dpranke@chromium.org
, Aug 31 2016Status: Duplicate (was: Untriaged)