Bug 46776

Summary: new-run-webkit-tests - clean up port/factory, add abstraction for the source tree
Product: WebKit Reporter: Dirk Pranke <dpranke>
Component: New BugsAssignee: Dirk Pranke <dpranke>
Status: RESOLVED WONTFIX    
Severity: Normal CC: abarth, eric, mihaip, ojan, ossy, rgabor, tony
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Other   
OS: OS X 10.5   
Attachments:
Description Flags
Patch
none
Patch ojan: review-

Dirk Pranke
Reported 2010-09-28 19:24:57 PDT
new-run-webkit-tests - clean up port/factory, add abstraction for the sourc e tree
Attachments
Patch (92.73 KB, patch)
2010-09-28 19:34 PDT, Dirk Pranke
no flags
Patch (93.33 KB, patch)
2010-09-28 19:58 PDT, Dirk Pranke
ojan: review-
Dirk Pranke
Comment 1 2010-09-28 19:34:06 PDT
Dirk Pranke
Comment 2 2010-09-28 19:58:29 PDT
Dirk Pranke
Comment 3 2010-09-28 20:00:29 PDT
Note that this patch contains the "better" fixes for the default configuration bug listed in bug 46278 (that had patches landed in r68268 and r68365.
Tony Chang
Comment 4 2010-10-04 12:00:53 PDT
Comment on attachment 69156 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=69156&action=review > WebKitTools/Scripts/webkitpy/layout_tests/port/options.py:38 > + def __init__(self, **kwargs): Is it possible to subclass the options class in optparse? What's wrong with just keeping a reference to the original optparse result?
Tony Chang
Comment 5 2010-10-04 12:01:42 PDT
Hit the wrong button: I was going to add: This patch is large and hard to review. Can you put the PortOptions changes into a stand alone patch first?
Dirk Pranke
Comment 6 2010-10-04 14:11:47 PDT
(In reply to comment #4) > (From update of attachment 69156 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=69156&action=review > > > WebKitTools/Scripts/webkitpy/layout_tests/port/options.py:38 > > + def __init__(self, **kwargs): > > Is it possible to subclass the options class in optparse? What's wrong with just keeping a reference to the original optparse result? 1) I wanted a generic "options" class that didn't depend on the optparse.Values definition specifically, but provided similar functionality for readers. It's almost like a mock fixture, while was still easy to construct. There also didn't seem to be any real value to subclassing that class. That said, I'm not all that familiar with the optparse.Values class, so maybe it's a good idea. I'll take another look. 2) I'm not sure I fully understand your second question (just keeping a reference to the original result), but if I do understand it, in the normal case (run_webkit_tests), we do keep the reference. All of this other code is for cases where we didn't actually call optparse to get a Values object.
Dirk Pranke
Comment 7 2010-10-04 14:12:21 PDT
(In reply to comment #5) > Hit the wrong button: > > I was going to add: > This patch is large and hard to review. Can you put the PortOptions changes into a stand alone patch first? I was afraid this might be the case. I will see if I can break it up into some more manageable chunks. Thanks for giving it a shot first!
Ojan Vafai
Comment 8 2010-10-04 14:14:07 PDT
Comment on attachment 69156 [details] Patch r- per comment #7
Tony Chang
Comment 9 2010-10-04 14:42:27 PDT
(In reply to comment #6) > 2) I'm not sure I fully understand your second question (just keeping a reference to the original result), but if I do understand it, in the normal case (run_webkit_tests), we do keep the reference. All of this other code is for cases where we didn't actually call optparse to get a Values object. Does that mean PortOptions is only used in unittests? Should it be called MockOptions?
Dirk Pranke
Comment 10 2010-10-04 14:46:24 PDT
(In reply to comment #9) > (In reply to comment #6) > > 2) I'm not sure I fully understand your second question (just keeping a reference to the original result), but if I do understand it, in the normal case (run_webkit_tests), we do keep the reference. All of this other code is for cases where we didn't actually call optparse to get a Values object. > > Does that mean PortOptions is only used in unittests? Well, sort of. The "options" argument is part of the Port public interface. Python doesn't have a good way AFAIK to express the concept of "some object implementing interface X" for me to indicate this. > Should it be called MockOptions? As per above, I'm not 100% comfortable with this. I'd be happy for the implementation to be called MockOptions, but I need some name for the actual interface object. Maybe optparse.Values and MockValues would be the way to go.
Dirk Pranke
Comment 11 2010-10-11 13:58:05 PDT
yeesh, getting back to this after two weeks, even I can't follow this patch. Gives me a whole new level of sympathy for trying to follow large patches. Closing this; I'll break it up into multiple separate changes.
Note You need to log in before you can comment on or make changes to this bug.