Build GTK 4 binaries #1422
Build GTK 4 binaries #1422
Conversation
Test Results 383 files - 102 383 suites - 102 6m 12s ⏱️ - 2m 2s Results for commit 7d668f6. ± Comparison against base commit b0413a8. This pull request removes 19 and adds 35 tests. Note that renamed tests count towards both.This pull request removes 1 skipped test and adds 3 skipped tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
This comment was marked as outdated.
This comment was marked as outdated.
| @@ -10,6 +10,7 @@ | |||
| * | |||
| * Contributors: | |||
| * Syntevo - initial API and implementation | |||
| * DUMMY CHANGE | |||
There was a problem hiding this comment.
Needs to be reverted before merge
|
Now Github succeed and Jenkins fails as expected: |
laeubi
force-pushed
the
build_gtk4
branch
3 times, most recently
from
e447b1c
to
397da2e
Compare
|
Given that I wanted to have a look at some of those deprecation errors in the near future, what version of GTK4 do you plan on compiling against? With #1421, SWT would require at least require 4.10 but then the build would have to continue despite the deprecations. With older versions, the build would succeed but then the PR no longer builds as the new methods don't exist yet. |
|
As GTK4 is WIP it should be fine to require as new version as needed . By the time this is ready for prime time that version would have made it to mainstream distros. |
|
Main goal is to build it with "what is available right now", if we have this working one can go step further to support a specific version. But still then one need to take care as using "the latest" might simply make it impossible for some linux distributions (e.g LTE) that not always have latest and greatest of libraries, but "latest stable" version. |
|
Even though GTK4 was added here: and container build seem to have completed https://ci.eclipse.org/releng/view/Miscellaneous/job/Build-Docker-images/732/ the build still complains:
@fredg02 anything else that needs to be done so the new container is visible? Can we do anything to verify the change is actually used? I didn't find anything in the log that indicates the actual used container has/version/date/.... |
We should have target Linux versions specified in the project plan, similar to Java versions.
|
I would agree with such version targeting when we discuss making GTK 4 default one. Unfortunately we are very far from it so by the time this discussion comes we will most likely have RHEL 10(most likely 11) and Ubuntu 26.04. |
|
One such impossible feature on RHEL 9 would be Browser support as even though there is gtk4 there is no webkitgtk4. |
|
That's why I said lets first get something compiled, then its easier to iterate, I tried to add some commands to find out actual installed versions for the github runners it is this versions: |
laeubi
force-pushed
the
build_gtk4
branch
3 times, most recently
from
ec1b98b
to
60dc09c
Compare
|
Jenkins CentOS currently using so it seems docker file change has had no effect... |
https://ci.eclipse.org/releng/view/Miscellaneous/job/Build-Docker-images builds docker images from https://github.com/eclipse-platform/eclipse.platform.releng.aggregator/tree/master/cje-production/dockerfiles. I don't know if there is a Jenkins job that actually builds https://github.com/eclipse-platform/eclipse.platform.swt/tree/master/container. I'd recommend to talk to project members that know more about the platform/swt docker builds. This should be more effective than you or me trying to decipher the inner workings of platform releng builds. I would also recommend to not use a matrix build while trying to get this running. It makes debugging harder than it should be. |
|
When you have found the right job to build the right docker image, I'd verify that it includes everything that is needed by running it locally. Once that is done, you can specify the sha256 of the image in your Jenkinsfile to make sure that the exact image is pulled. |
|
@fredg02 So according to https://ci.eclipse.org/releng/job/Build-Docker-images/732/artifact/eclipse.platform.releng.aggregator/cje-production/dockerfiles/swt_9_build.log and https://ci.eclipse.org/releng/job/Build-Docker-images/732/artifact/eclipse.platform.releng.aggregator/cje-production/dockerfiles/push-swt_9_build.log image should be built and pushed but looking at https://hub.docker.com/layers/eclipse/platformreleng-centos-swt-build/9/images/sha256-31294c0be3473791b82c8f6cbb9e9e1bf5ff42701553eed6a5e17f5f427c59e4?context=explore image was last updated 2 months ago. I have no idea how to help more here. |
|
As noted above, https://ci.eclipse.org/releng/job/Build-Docker-images/ is not building the Dockerfile that @laeubi modified. |
|
I changed the file here: And Jenkins config says it runs do I miss something obvious? |
|
@sravanlakkimsetti can you maybe shade some light here, the Jenkins file config and collection of shellscripts seems not easy to understand :-\ I even wonder if it would not be easier to have one Jeankinsfile (in git) that includes the shell calls directly instead of many different shell scripts with only a few line in it. |
Ok. That was not obvious to me, based on the comments here. |
|
Finally the docker images was updated and now we have GTK4 at the build node, this is the used GTK version and it shows a lot of deprecation warnings: See https://ci.eclipse.org/releng/job/eclipse.platform.swt/job/PR-1422/14/pipeline-console/?selected-node=195 |
That were exaclty my toughts as well when I came along the docker images in the releng-aggregator repo the last time, but I never had the time to do that. But I think there is no reason that speaks against doing the latter if the Job is maintained in the releng.aggregator repo. In order to not lose it again: Lets have further discussion about improvements of that process there. |
|
GTK3+4 Builds with the new docker image succeed! But the arm and alike fail due to missing gtk4 :-\ |
|
@fredg02 can I somehow run my docker image on the native (e.g. |
|
If the native build agent's have docker installed, we could maybe launch another docker node from that agent? And we could maybe even build a docker-image for SWT on the fly using: If that works as desired/hoped, we could even maintain the docker-image in this repo without the need to push it to docker-hub. |
One drawback is that building a docker image can take some time and requires download of a lot of stuff, so I think using a prebuild image from a registry can still be good. On the other hand on a "real" machine one can probably benefit from caching (in both cases). Anyways as ther is no easy "out of the box" way I first will head on to make the lib available on the machines: |
Currently the GTK4 binaries are not build as part of the build, this has several drawbacks: 1) If anything is adjusted for GTK4 part it might break without notice 2) We have no GTK4 binaries by default This enables *compilation* of the gtk4 parts to see at laest everything can be compiled.
Currently the GTK4 binaries are not build as part of the build, this has several drawbacks:
This enables compilation of the gtk4 parts to see at least everything can be compiled.
The following has to be checked: