[Webkit-unassigned] [Bug 186771] [WPE]: Add a way to setup our development environment inside flatpak

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186771

Carlos Alberto Lopez Perez <clopez at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clopez at igalia.com

--- Comment #6 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
Comment on attachment 342946
  --> https://bugs.webkit.org/attachment.cgi?id=342946
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=342946&action=review

> Tools/ChangeLog:43
> +        The worflow works as follow:
> +
> +        1. Building WebKit
> +        
> +          # No arguments, setup a WPE environment on the first run, and launch MiniBrowser once done (use `--gtk` to build WebKitGTK)
> +          $ webkit-flatpak
> +
> +          # Build anything required to build WebKit itself if needed, it builds only WebKit itself when nothing specified
> +          $ webkit-flatpak --build-app
> +
> +        When building webkit, we mount `WebKit/` sources into `/app/webkit` inside the sandbox to have a more reproducible build and so that
> +        we can potentially rsync content of `WebKitBuild` from a build server without problem. The `build-webkit` script is used inside the sandbox,
> +        (at /app/webkit/Tools/Script/build-webkit) and the same `--cmarkargs` and `--makeargs` are exposed.
> +
> +        Also `WebKitBuild/WPE/Release` is mounted on `/app/webkit/WebKitBuild/Release` so that we can build several ports in the same worktree.
> +
> +        To be able to run layout tests, the httpd server is built inside the sandbox and Xvfb is built for the GTK port.
> +
> +        2. Running Layout tests
> +
> +        We reuse the run-webkit-tests script and all arguments after `--test` are passed to that script.
> +
> +          $ webkit-flatpak [--gtk] [--debug] --tests ...
> +
> +        3. Retrieve stacktrace
> +
> +        Since everything runs inside a flatpak sandbox, gdb needs to be run from within the sandbox, the script exposes a way to do it
> +        easily with the `--gdb` option:
> +
> +          $ webkit-flatpak --gdb [-m COREDUMPCTL MATCHES]
> +
> +        The Layout test `GDBCrashLogGenerator` has been taugth how to use that and is able to retrieve stacktrace as with the jhbuild based workflow.
> +

I think we should make the usage of this as transparent of possible, so if possible the way of building-webkit and running tests should remain unchanged.
The rationale is:
1. Avoid users having to learn about a new way of running tests or building webkit.
2. Avoid having to modify all the buildbot configs to pass new arguments.

Currently, the JHBuild tooling automatically runs everything under the JHBuild environment if possible (no need to pass any special argument to the script run-webkit-tests, etc). It does so by simply checking the existence of the directory WebKitBuild/Dependencies${PORT} and if that directory exists it just enters into the jhbuild environment before running any test or building anything. Check the function enter_jhbuild_environment_if_available() that its automatically called from the layout test scripts, run perf test scripts as well as from the API test scripts.


So I think this will work better if the arguments and command needed to build webkit and run the test steps remain unchanged.
The scripts doing this should somehow check if the flatpak environment has been initialized and then try to use it automatically, otherwise continue with current behaviour (try to use jhbuild)

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180618/5557d0c1/attachment.html>