Bug 31736

Summary:

Pass the port information to the child process

Product:

WebKit

Reporter:

Adam Barth <abarth>

Component:

Tools / Tests

Assignee:

Nobody <webkit-unassigned>

Status:

RESOLVED FIXED

Severity:

Normal

CC:

darin, eric

Priority:

Version:

528+ (Nightly build)

Hardware:

All

OS:

All

Attachments:

Description	Flags
Patch	none
Patch	none
Patch	eric: review+

Adam Barth

Reported 2009-11-20 11:52:24 PST

We need to do this so the child process knows what to build!

Attachments
Patch (5.32 KB, patch) 2009-11-20 11:53 PST, Adam Barth	no flags	Details Formatted Diff Diff
Patch (5.27 KB, patch) 2009-11-20 12:55 PST, Adam Barth	no flags	Details Formatted Diff Diff
Patch (4.91 KB, patch) 2009-11-20 12:56 PST, Adam Barth	eric: review+	Details Formatted Diff Diff
Show Obsolete (2) View All Add attachment proposed patch, testcase, etc.

Adam Barth

Comment 1 2009-11-20 11:53:52 PST

Created attachment 43601 [details] Patch

Darin Adler

Comment 2 2009-11-20 12:15:28 PST

Comment on attachment 43601 [details] Patch What this makes me think is we need names for the ports that are consistent across the tools and source code. I worry that we call it MAC in the source code and AppleMacPort in the tool. r=me

Eric Seidel (no email)

Comment 3 2009-11-20 12:40:56 PST

Comment on attachment 43601 [details] Patch I sent you down the wrong path Adam. :( As we discussed over lunch, I think we should kill AppleMacPort for now and do a DefaultPort instead since this will do bad things when running bugzilla-tool on other platforms. Thanks for the review darin!

Eric Seidel (no email)

Comment 4 2009-11-20 12:42:08 PST

Yeah, the AppleMacPort idea came out of concerns that we'll eventually be building other "Mac" ports from the tool. But in the end we realized (after long discussions at lunch) that this was the wrong approach for this part of the tooling. We need the concept of a "default" port because these ports are more about what flags you pass to the tools to control their behavior, and less about what port you're actually buidling.

Eric Seidel (no email)

Comment 5 2009-11-20 12:43:57 PST

Another way we could have solved this is by teaching all the tools to understand --apple-mac, --apple-win, --chromium, --qt etc. But right now they just do whatever the "default" for the platform is.

Adam Barth

Comment 6 2009-11-20 12:55:12 PST

Created attachment 43607 [details] Patch

Adam Barth

Comment 7 2009-11-20 12:56:16 PST

Created attachment 43608 [details] Patch

Eric Seidel (no email)

Comment 8 2009-11-20 13:02:44 PST

Comment on attachment 43608 [details] Patch Looks good. Adam and I talked about it again in person, and decided to go back to "Mac" per your suggestion Darin. :) Personally I would like all the repository to move to more explicit defines, but that's a bias to express in another bug.

Adam Barth

Comment 9 2009-11-20 13:03:34 PST

Committed r51253: <http://trac.webkit.org/changeset/51253>

Darin Adler

Comment 10 2009-11-20 13:10:52 PST

(In reply to comment #8) > Personally I would like all the > repository to move to more explicit defines, but that's a bias to express in > another bug. Sure, it would be great to figure out clear naming and reform how we do platforms — Maciej had a proposal for how to do that. And I am well aware that Chrome, GTK, Qt, and Wx all can compile to run on Mac.

Adam Barth

Comment 11 2009-11-20 13:24:46 PST

For this patch, I changed it to "mac" per Darin's suggestion. We can rename it later in some grand renaming project.

Note You need to log in before you can comment on or make changes to this bug.