Community
Participate
Working Groups
I had to build natives to test a GTK patch, and I hit the wall because GTK3 support didn't work out of the box. Sravan revealed that I need to add this to /org.eclipse.swt.gtk.linux.x86/build.xml: <property name="machine_gtk3" value="localmachine"/> It looks like bug 428656 fixed this for the Maven build, but the workspace build should also work without this hack. On a related note, I had to change the "targets" property to ... <property name="targets" value="install"/> ... because I didn't find all XULRunner dependencies, and WebKit support was good enough for me. Skipping XULRunner by default would be much more appropriate than skipping GTK3.
Defaulting to GTK3 but not compiling it by default is kind of weird I agree. Adding machine_gtk3=localmachine in fragment build.xml has the potential of breaking existing builders if there are still platforms for which gtk2 and gtk3 builds happen on different machines @IBM builders (Arun please correct me if wrong). Building GTK3 shouldn't be conditionalized on local vs. remote vailable, it should be enabled/disabled on another var per os/arch tuple (fragment build.xml files), always default to local and if some param passed do it remote (if this use case is still needed). This is smth that can't be touched from non-IBMers (due to exact knowledge/access to builders needed) until bug 476642 is resolved but the number of bumpers there are too many and require more groups involvement than manageable so really slow going. About XULRunner - it's swt integration is exercise for the sake of the exercise on any recent distro as no one has that old xulrunners needed for swt to work with. This is really nasty area in getting people onboard for swt but thankfully the maven build and terminal build.sh work reliably enough so I just recommend people building the natives at the console (sigh). I'm really happy to see others see the current state not that good.
(In reply to Alexander Kurtakov from comment #1) Thanks for the background. It's not high-priority. > Adding machine_gtk3=localmachine in fragment build.xml has the potential of > breaking existing builders if there are still platforms for which gtk2 and > gtk3 builds happen on different machines @IBM builders Yeah, I didn't mean to release this workaround, but I just wanted to write it down somewhere, so that I or others can find it. > ... always default to local and if some param passed > do it remote (if this use case is still needed). Yup. Funny thing about XULRunner: I just changed my Windows install to use XULRunner, because I was forced to upgrade to IE 11. I can't stand IE's font smearing. XULRunner looks better and respects my OS settings.
Is this still an issue?
(In reply to Eric Williams from comment #3) > Is this still an issue? Yeah its still an issue. Need to add <property name="machine_gtk3" value="localmachine"/> to <binaries repo>/<gtk binaries>/build.xml
(In reply to Sravan Kumar Lakkimsetti from comment #4) > (In reply to Eric Williams from comment #3) > > Is this still an issue? > > Yeah its still an issue. Need to add > <property name="machine_gtk3" value="localmachine"/> > to <binaries repo>/<gtk binaries>/build.xml Okay. Is it feasible to target this for 4.9?
In 4.10 only GTK3 is built.
