[webkit-help] Automatic Layout Test Execution for Cross Compiled Platforms

Mon Nov 12 05:41:43 PST 2012

Peter, really awesome. Thanks for your detailed explanation. Yes, I'm working on a platform where the layout test has to be executed on the embedded device. I will follow your approach to bring up layout test environment and let you know for any further assistance.

Sent from my Xperia™ smartphone 

Peter Beverloo <peter at chromium.org> wrote:

>Hi Arunprasad,
>
>I'll briefly explain how Android compiles for WebKit, and runs the layout
>tests. It has become quite a complicated system due to our requires (most
>notably, to be able to run tests on non-rooted devices) and is still
>undergoing a lot of changes. We should probably document this publicly
>somewhere at some point, but I'd rather wait until it has stabilized
>somewhat more.
>
>*Compiling (Chrome|WebKit) for Android*
>The project generation tool we use, gyp, has support for defining the CC,
>CXX, AR, LINK etc. programs. We use this and cross-compile all sources to
>Android, using the Android NDK's toolchain. The host we currently support
>is Linux, but at some point in time we may start supporting Mac as well.
>
>1) We run envsetup.sh <
>http://src.chromium.org/viewvc/chrome/trunk/src/build/android/envsetup.sh?view=markup>.
>This calls envsetup_functions.sh <
>http://src.chromium.org/viewvc/chrome/trunk/src/build/android/envsetup_functions.sh?view=markup>,
>which, in the sdk_build_init() function, passes the android_toolchain
>argument to gyp, which will be handled by build/common.gypi. The toolchain
>itself lives in the Chromium repository <
>http://git.chromium.org/gitweb/?p=android_tools.git;a=tree>.
>2) Gyp makes sure that CC_target, CXX_target etcetera are correctly set
>when compiling the source files. All of these will be cross-compiled and
>linked.
>3) After everything has been compiled, we create the necessary Java
>libraries (which talk to the Android SDK), and create the .apk packages. We
>get DumpRenderTree.apk for running layout tests.
>
>*Running layout tests*
>The test running framework (the Python side, being new-run-webkit-tests)
>runs on the host, whereas DumpRenderTree itself runs on the target
>(device). The test running framework follows these steps:
>
>1) Install the .apk on the device, push all necessary files to the device.
>This does *not* include the layout tests themselves.
>2) Create a file in /data/local/tmp/ for setting the command line flags
>used by DRT. We ask the test runner to read this file and apply the flags.
>3) Set up a "Forwarder". The forwarder allows the device to access a web
>server running on the host by reverse-forwarding the ports. This runs on
>both the host as the target device. This is how we serve all the layout
>tests, including resources.
>4) Start DumpRenderTree. We create FIFO pipes to talk to the process, as
>Android applications are being run asynchronous and we can't access their
>stdin/stdout in another way.
>
>For each test, we write the test URL to the stdin FIFO. DumpRenderTree will
>request the test and all its resources over the forwarder and runs it. The
>result, usually either TEXT or an IMAGE blob, will be written to the
>stdout, which we then return to the layout test framework itself.
>
>The main tricks are to request the tests over a web server instead of local
>files (meaning you don't have to transfer all of LayoutTests/ to the
>device) and use FIFOs to talk to DumpRenderTree. There are a few more
>things we have to figure out in order to make it not require root access
>anymore, but we're getting there.
>
>I hope this clarifies things a bit. If you have any further questions,
>please feel free to ask them, I'd be happy to help out.
>
>I presume you're working on a project that wants to run layout tests on
>devices. This is absolutely awesome, great to hear! The WebKit GTK and Qt
>ports are looking in to doing the same, and Research In Motion's port is
>also getting there (or doing it already?). Higher accuracy on test suites
>means that all of us can move forward on making the mobile web more awesome
>:-).
>
>Cheers,
>Peter
>
>
>
>
>On Thu, Nov 8, 2012 at 11:41 AM, Arunprasad Rajkumar <ararunprasad at gmail.com
>> wrote:
>
>> Hi Peter,
>>
>> How you guys running layout tests in Android Chrome? Are you guys running
>> Tools/Scripts/new-run-webkit-tests script in Android device (or) it is been
>> triggered from the host?
>>
>> Usually things are cross compiled right? How the build system & target
>> system(where webkit runs) are interconnected?
>>
>> On 8 November 2012 16:14, Ryosuke Niwa <rniwa at webkit.org> wrote:
>>
>>> You might be interested in looking into how Chromium Android port solve
>>> this problem. See
>>> Tools/Scripts/webkitpy/layout_tests/port/chromium_android.py.
>>>
>>> On Thu, Nov 8, 2012 at 2:36 AM, Arunprasad Rajkumar <
>>> ararunprasad at gmail.com> wrote:
>>>
>>>>
>>>> Hello Developers,
>>>>
>>>> I'm working on a embedded platform where I need to automate the Layout
>>>> Tests. From the Tools/Scripts/new-run-webkit-tests &
>>>> https://www.webkit.org/blog/1456/layout-tests-practice/ I understood
>>>> like it requires python to run layout tests, since the web server & related
>>>> things implemented in python. But the platform I'm working on is a resource
>>>> constraint one & doesn't have these run-times(python,perl,..etc).
>>>>
>>>> Do you guys have any suggestions for my question? I'm thinking to use
>>>> js-test-driver <http://code.google.com/p/js-test-driver/> for some of
>>>> the non webkit specific tests. Will the same thing can be used for WebKit
>>>> Layout tests.
>>>>
>>>> Thanks in advance.
>>>>
>>>> Kind Regards,
>>>> Arun.
>>>> --
>>>> *Arunprasad Rajkumar*
>>>> http://in.linkedin.com/in/ararunprasad
>>>>
>>>>
>>>> _______________________________________________
>>>> webkit-help mailing list
>>>> webkit-help at lists.webkit.org
>>>> http://lists.webkit.org/mailman/listinfo/webkit-help
>>>>
>>>>
>>>
>>
>>
>> --
>> *Arunprasad Rajkumar*
>> http://in.linkedin.com/in/ararunprasad
>>
>>
>>
>>
>> --
>> *Arunprasad Rajkumar*
>> http://in.linkedin.com/in/ararunprasad
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-help/attachments/20121112/43e8e1ac/attachment-0001.html>