[webkit-dev] Hosting precompiled `jsc` binaries for Linux

[Carlos Alberto Lopez Perez]

On 08/12/17 18:07, Lucas Forschler wrote:
> If the GTK team wanted to support making these accessible,
> they have everything they need. They could either choose to open up
> their firewall so external folks could access them. Or, they could put
> full archives on build.webkit.org <http://build.webkit.org> (which would
> be transferred to s3/webkit build archives).
> 
> Maybe someone over there would be willing to take on this work if it is
> in their budget. (Both time and bandwidth)
>


Hi Lucas, Mathias, et all.

This is bit more complex that it seems. I will try to explain.

The built products the WebKitGTK+ bots currently generate are being
uploaded to a local server that was only reachable from the Igalia
intranet [1]. I have just changed that, and the build products should
be now accesible for everybody at:

http://webkitgtk-release.igalia.com/built-products/
(also available via https if you prefer)

Keep in mind that currently we delete the built products after 10 hours,
so don't expect to find there more than the very last few builds.
That is just enough time for the test bots to download and test them.

We are happy on configuring a less aggressive purging of this files to
keep them available for much longer. We can as well make this resource
available from a more official domain (like webkit.org or webkitgtk.org)
 
But before doing that I will like to know if this files will be useful
for you in the end (or not). See below.

If you download one of those build products and try to run it on your dev
machine you are likely to have some problems with the shared libraries.

The main issue is that this binaries are linked against a bunch of libraries
that we build in a internal JHBuild, and will likely differ from the ones
shipped by your distro.

To test it, you can download one of this zip files and try running:

for JSC:
LD_LIBRARY_PATH=$(pwd)/lib bin/jsc

for WebKit:
LD_LIBRARY_PATH=$(pwd)/lib WEBKIT_EXEC_PATH=$(pwd)/bin WEBKIT_INJECTED_BUNDLE_PATH=$(pwd)/lib bin/MiniBrowser


Perhaps the JSC binary works because it has few dependencies (libicu and
glib mainly), but I doubt the WebKit one will do. Your mileage may vary.


And this will be only for the 64-bit builds. Our current 32-bit buildbots
are test&build ones, which means they don't currently generate and upload
a built-product. They just test it after building it and then discard it.
There maybe the possibility of adding an extra step to add the upload in
case you find this built products useful.

Trying to look forward for a more elegant solution I tried to generate a
static build of JSC with the JSCOnly port, but I failed when trying to
link statically with libicu. I have reported that on the bug below:
https://bugs.webkit.org/show_bug.cgi?id=180678


Let me know your thoughts.

Regards
-------

[1]
We do that because the server that generates the built product as well as the
others that donwload it for testing are on the same LAN. So it makes little
sense for us to daily upload and download gigabytes worth of data to Internet, 
when we can just serve the resources locally.

Doing that will make every build slower because then the build-only bot
will have to wait for an upload to Internet rather than to a local server,
as well the test-only bot will have to wait for a download from Internet. 
Our bandwith to Internet is much less than a gigabit LAN.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 897 bytes
Desc: OpenPGP digital signature
URL: <http://lists.webkit.org/pipermail/webkit-dev/attachments/20171212/e986b66e/attachment.bin>