[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

--- Comment #10 from Carlos Alberto Lopez Perez <clopez at igalia.com> ---
(In reply to Thibault Saunier from comment #9)
> (In reply to Michael Catanzaro from comment #8)
> > That's not what Carlos Lopez is asking for. He is asking you to modify our
> > *existing* scripts to use flatpak. E.g. for build-webkit and
> > run-webkit-tests to both make use of webkit-flatpak. Then we can remove the
> > jhbuild support if everything is working fine after a short while.
> 
> I know yes...
> 
> The main problem is mostly about the fact that in flatpak we should run
> **everything** in the sandbox (server is not on the host.. etc) so the
> implementation will be a bit different.
>  

Why should be different?

Le't me rephrase me previous point. I think it maybe I didn't make it clear enough.

This patch proposes that for building webkit inside the flatpak and running tests with it, I need to do:

Tools/Scripts/webkit-flatpak
Tools/Scripts/webkit-flatpak --build-app
Tools/Scripts/webkit-flatpak [--gtk] [--debug] --tests ...

And I ask to be able to do instead:

Tools/Scripts/webkit-flatpak
Tools/Scripts/build-webkit --gtk
Tools/Scripts/run-webkit-tests --gtk


To make that possible the scripts build-webkit and run-webkit-tests should detect that the flapak environment has been initialized and is ready to be used, and then they should enter into it automatically before doing anything else.

I understand the problem of entering into the flatpak environment automatically is a bit trickier than in the case of JHBuild, because with JHBuild is just a matter of changing the process environment, but here we need to execute a new process inside a new chroot/namespace... 

I hope we can find a good way of making this work easily, perhaps a helper can be added that takes care of forking and re-exec inside the flatpak meanwhile keeping the stdout/stderr descriptors shared with the caller? Just a wild idea.. perhaps it doesn't work well in practice.

> > The tricky part here is the language barrier (perl).
> 
> Yeah... that is also one of the reason I would like to avoid putting my
> hands in there :-)

There is no much perl there... only for build-webkit, but the others for the tests (layout, perf and API) are all python.

-- 
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/e333e1d7/attachment-0001.html>