75037 2011-12-21 14:30:51 -0800 META: clean up port creation in webkitpy.layout_tests 2012-08-08 16:48:23 -0700 1 1 1 Unclassified WebKit Tools / Tests 528+ (Nightly build) Unspecified Unspecified RESOLVED FIXED NRWT P2 Normal --- 76474 75590 75764 76016 76084 76123 76215 76475 71403 1 dpranke webkit-unassigned abarth eric ojan rakuco tony oldest_to_newest 525603 0 dpranke 2011-12-21 14:30:51 -0800 Right now there's too much logic for creating different types of Port objects in webkitpy, and it's scattered across too many different places. We should clean this up. Roughly, I think the functionality that is needed is: 1) create the "right" port by default on a platform (e.g., running on Mac Lion gets you apple-mac-lion by default - needed for interactive use by devs) 2) create the "right" port for a given implementation on a platform (e.g., if you say --chromium on Mac Lion you get chromium-mac-lion by default - needed or interactive use by devs) 3) create a fully qualified port (--platform chromium-win-xp gets you a ChromiumWin port configured for XP baselines, regardless of what operating system you're running on - needed by rebaselining tools, other tools) And possibly also: 4) supporting --platform chromium-win (or --platform google-chrome-win) on windows (I think the chromium buildbots might use this, but it might be better to add a --google-chrome option to mirror the --chromium option instead) 5) pick a port that actually is built, even if it is not the default (so if I have a chromium checkout built on mac, it picks that up if there's no apple port built). Things that I think we probably don't need to support: a) --platform chromium-win on a non-windows port b) the cpu/gpu graphics type; I think the plan is to merge this into the regular chromium port, so this can go away Cleaning this up all at once would probably get messy, so I have a rough plan of attack: I. merge the get() routines in chromium_gpu.py and google_chrome.py into factory.py II. extract all of the port_name parsing logic out of the port constructors into separate staticmethods III. figure out if we can merge the staticmethods into factory.py and/or call them prior to constructing port objects IV. modify the Port objects to take a required, fully-qualified port_name in the constructor -> no more logic in the constructors will be left I'm going to start working on this as written, but let me know if anyone has any thoughts on this. 535181 1 dpranke 2012-01-12 14:38:50 -0800 final (?) patch posted in bug 76215. 669683 2 dpranke 2012-07-13 19:30:21 -0700 resetting the owner in case someone else wants to take a look, as these bugs aren't on my immediate to-do list. 690922 3 dpranke 2012-08-08 16:48:23 -0700 I think this is as cleaned up as it's likely to get for a while. If people have other specific enhancements they'd like to see we should file separate bugs for them.