Bug 106745 – [chromium/mac] In a webkit-in-chromium build, `run-webkit-tests --chromium` never uses binaries built by `build-webkit --chromium`

• Status: RESOLVED
• Resolution: WONTFIX
• Component: WebKit Misc.

[Nico Weber]

In a webkit-in-chromium build, layout_tests/port/chromium.py's _static_build_path looks in these places:

/Users/thakis/src/chrome/src/xcodebuild/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree
/Users/thakis/src/chrome/src/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree
/Users/thakis/src/chrome/src/third_party/WebKit/xcodebuild/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree
/Users/thakis/src/chrome/src/third_party/WebKit/out/Release/DumpRenderTree.app/Contents/MacOS/DumpRenderTree

This finds the DRT binaries in Chromium's build directories and it finds the DRT in the webkit ninja/make build directory, but it doesn't find the DRT binary in third_party/WebKit/Source/WebKit/chromium/xcodebuild.

From what I can tell, this has never worked (?).

[Dirk Pranke]

Correct, I wouldn't expect it to look there. 

Currently, the logic will look in what it thinks to be the top of the chromium checkout, and then the top of the webkit checkout. It would not know how to deal with two nested chromium checkouts. "the chromium checkout" is defined by looking at the path of the python file, so if we're in a webkit-in-chromium checkout, we'll always pick the enclosing chromium checkout, rather than the stuff added by update-webkit.

I'd actually be surprised if update-webkit --chromium even worked properly in this scenario (I guess maybe the correct thing to do would be to end up with two copies of the deps?). I'm not sure that there's a strong reason to support it.

[Nico Weber]

`update-webkit --chromium` downloads a second copy of the deps (which I guess is the "right thing" – I sometimes build from third_party/WebKit and assume that to work like a standalone checkout).

Since ninja works fine, this bug isn't important for me personally though.

[Dirk Pranke]

when would third_party/WebKit/Source/WebKit/chromium/xcodebuild get used? Won't build-webkit put the output in third_party/WebKit/xcodebuild (assuming we're using xcode)?

[Nico Weber]

(In reply to comment #3)
> when would third_party/WebKit/Source/WebKit/chromium/xcodebuild get used? Won't build-webkit put the output in third_party/WebKit/xcodebuild (assuming we're using xcode)?

Dunno, I'd expect `build-webkit --chromium` to put its output in Source/WebKit/chromium/xcodebuild. It's fine that the test runner looks in my outer-level chromium build directory for binaries, but the webkit build shouldn't put files there imho.

(But as said above, I don't care about this use case myself, so my opinion shouldn't count for anything.)

[Dirk Pranke]

(In reply to comment #4)
> (In reply to comment #3)
> > when would third_party/WebKit/Source/WebKit/chromium/xcodebuild get used? Won't build-webkit put the output in third_party/WebKit/xcodebuild (assuming we're using xcode)?
> 
> Dunno, I'd expect `build-webkit --chromium` to put its output in Source/WebKit/chromium/xcodebuild. It's fine that the test runner looks in my outer-level chromium build directory for binaries, but the webkit build shouldn't put files there imho.
>


Oh, I see the confusion, I was thinking that build-webkit --chromium put its output in third_party/WebKit/xcodebuild , but its putting it into Source/WebKit/chromium/xcodebuild. Did it always do that? I would've sworn it when into the upper directory.

[Nico Weber]

I believe it's always done that, but I'm not sure.

[Tony Chang]

It's always done that.  On Windows, I think the output is always at WebKit/Source/WebKit/chromium/build/{Debug,Release}.  This is because the gclient sync root directory is WebKit/Source/WebKit/chromium.  We had to do some special hacks to move the Makefile output to WebKit/out.

[Tony Chang]

That said, it would be nice if we could move all the outputs of build-webkit --chromium into WebKitBuild like every other port.

[Dirk Pranke]

(In reply to comment #6)
> I believe it's always done that, but I'm not sure.

Well, doesn't matter, really. I guess the important point is that third_party/WebKit/xcodebuild is not going to be populated, and so that part of the logic is just wrong. That should probably be fixed.