building webkit
Tom Schindl
tom.schindl at bestsolution.at
Sat Aug 25 19:03:05 UTC 2018
I think in the longrun using the adoptjdk approch is the one to follow.
Tom
Von meinem iPhone gesendet
> Am 25.08.2018 um 19:01 schrieb Arunprasad Rajkumar <arunprasad.rajkumar at oracle.com>:
>
> As Kevin mentioned, I tried to make WebKit build work on Travis with few hacks(using ccache). It seemed to be working, but not consistently all the time.
>
>> How does AdoptJDK solve problems of long build times? Can we not adopt
>> their build chain/infrastructure?
>
> Looks like they host their own CI infra without relying on Travis/Appveyor.
>
>> On 25-Aug-2018, at 6:34 PM, Tom Schindl <tom.schindl at bestsolution.at> wrote:
>>
>> Hi,
>>
>> How does AdoptJDK solve problems of long build times? Can we not adopt
>> their build chain/infrastructure?
>>
>> Tom
>>
>>> On 25.08.18 15:00, Kevin Rushforth wrote:
>>> Yes, this should be possible to do. Even without build changes, we could
>>> build just the SDK + WebKit (and maybe media, too, or maybe a separate
>>> job for that). The problem is that even building just WebKit takes
>>> longer than Travis / Appveyor will allow. See PR #121 [1]. Arun can
>>> comment further.
>>>
>>> Irrespective of the above, as long as a compatible SDK (meaning an SDK
>>> built from the current tip of jfx-dev/rt) is available for download, the
>>> build can point to it, and will use the jfxwebkit and media natives from
>>> that build. So if we had a nightly build available, most developers
>>> could use that (it wouldn't help anyone making native changes to WebKit,
>>> but would be fine for most developers who don't).
>>>
>>> -- Kevin
>>>
>>> [1] https://github.com/javafxports/openjdk-jfx/pull/121
>>>
>>>
>>>> On 8/25/2018 12:27 AM, Johan Vos wrote:
>>>> We currently don't build WebKit with Appveyor/Travis, as the combined
>>>> build
>>>> time would be too long.
>>>>
>>>> I'm wondering though if it would be possible to have separate build jobs
>>>> for webkit? Typically, when building a JavaFX SDK, the webkit part is
>>>> where
>>>> things go wrong (if they go wrong), and have that somehow automated would
>>>> be very helpful.
>>>>
>>>> - Johan
>>>
>>
>> --
>> Tom Schindl, CTO
>> BestSolution.at EDV Systemhaus GmbH
>> Eduard-Bodem-Gasse 5-7. A-6020 Innsbruck
>> Reg. Nr. FN 222302s am Firmenbuchgericht Innsbruck
>
More information about the openjfx-dev
mailing list