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
> :
>
> As Kevin mentioned, I tried to make WebKit build work on Travis with few
> hacks(using ccache). It seemed to be working, but not
Build time is kinda constant, with 2 cores, It would take around 1hr 15mins to
complete. I need to restart the job several times to complete the incremental
build with ccache doing some object file caching.
> On 25-Aug-2018, at 10:47 PM, Johan Vos wrote:
>
> Is the non-consistency due to
Is the non-consistency due to varying build times, which may lead to
canceled jobs?
On Sat, Aug 25, 2018 at 7:12 PM Arunprasad Rajkumar <
arunprasad.rajku...@oracle.com> wrote:
> As Kevin mentioned, I tried to make WebKit build work on Travis with few
> hacks(using ccache). It seemed to be
Using AdoptOpenJDK infrastructure would be great, but we're sort of stuck
on Ansible. The AdoptOpenJDK build farm uses Ansible for provisioning
systems with the required components. We're almost there with an Ansible
script for Linux, but Windows turns out to be extremely complicated (at
least for
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
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
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
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
Hi David,
Thanks for pointing me in the right direction. Although I've almost lost
hope before finally succeeding. I tried various other approaches on the
way, but finally, what I did was very simple. It could be possible to
create a separate configuration (i.e. LINUX32) with some additional
Hi Again,
The idea that comes to my mind is the following: would it be possible to
cross-compile the openjfx on the 64 bit Linux using 64 bit tools, but
targeted at 32 bit Linux? What would have to be changed in build
environment to accomplish that? I imagine the environment would have to
My question to the list is: How do you guys produce 32 bit libjfxwebkit.so
with debugging symbols? Have you been able to? Do you have any special tricks
in your sleeves?
Oh man, you’re in unchartered waters. Building webkit is a royal pain in the
neck :-(. You’ve already ventured farther
On 5/28/14, May 28, 9:47 AM, Peter Levart wrote:
Hi Again,
The idea that comes to my mind is the following: would it be possible to
cross-compile the openjfx on the 64 bit Linux using 64 bit tools, but targeted
at 32 bit Linux? What would have to be changed in build environment to
accomplish
Note that there is a bug filed on building webkit with debug symbols on
Windows/32 and Linux/32:
https://javafx-jira.kenai.com/browse/RT-36147
If you have a 64-bit Linux system, then it should work.
-- Kevin
David Hill wrote:
On 5/28/14, May 28, 9:47 AM, Peter Levart wrote:
Hi Again
13 matches
Mail list logo
