I’m running into some build problems on OSX. It seems that the GTK module assumes that if a system is NT that gdkwin.h is used and otherwise gdkx.h is used. Unfortunately, it seems that on some builds of GTK/GDK for OS X, neither of those is correct and that gdkquartz.h should be used. I’m guessing that some configure tests are needed to determine which of the 3 files is actually present. However a quick look at configure.in leaves me unsure how best to include that. Anyone with more expertise in the GTK module’s inner workings care to weigh in?
Bill
On Sun, Mar 12, 2017 at 3:51 AM, H William Wellliver III william@welliver.org wrote:
I’m running into some build problems on OSX. It seems that the GTK module assumes that if a system is NT that gdkwin.h is used and otherwise gdkx.h is used. Unfortunately, it seems that on some builds of GTK/GDK for OS X, neither of those is correct and that gdkquartz.h should be used. I’m guessing that some configure tests are needed to determine which of the 3 files is actually present. However a quick look at configure.in leaves me unsure how best to include that. Anyone with more expertise in the GTK module’s inner workings care to weigh in?
I'm far from an expert on either the module or configure.in, but I did some experimentation. The result is in branch rosuav/support-gdk-quartz, and it adds three header file probes to the configuration. Then, since three-way logic is a lot more verbose than two-way, I've removed it from all the places where it's currently done, and put it into pgtk.h (which they all include). This will probably slow down compilation slightly, but AFAIK it shouldn't have any run-time significance.
Can you test it on OSX? And ideally Windows?
ChrisA
Thanks for taking a stab at it, Chris. I will have a look this weekend... just got a fresh OSX VM running so I can test things out pretty easily.
Getting a build attempt on Windows is possible but may take me a few days to get the build environment running on my new build machine. Stay tuned.
Bill
On 2017-03-13 19:06, Chris Angelico wrote:
I'm far from an expert on either the module or configure.in, but I did some experimentation. The result is in branch rosuav/support-gdk-quartz, and it adds three header file probes to the configuration. Then, since three-way logic is a lot more verbose than two-way, I've removed it from all the places where it's currently done, and put it into pgtk.h (which they all include). This will probably slow down compilation slightly, but AFAIK it shouldn't have any run-time significance.
Can you test it on OSX? And ideally Windows?
ChrisA
On Sat, Mar 18, 2017 at 3:55 AM, H William Wellliver III william@welliver.org wrote:
Thanks for taking a stab at it, Chris. I will have a look this weekend... just got a fresh OSX VM running so I can test things out pretty easily.
Getting a build attempt on Windows is possible but may take me a few days to get the build environment running on my new build machine. Stay tuned.
Just rebased the rosuav/support-gdk-quartz branch onto current 8.1 (trivial since there'd been no changes to GTK2) so you'll get a forced-update warning when you grab this.
I would *love* to see an easy way to get Pike installed on a Mac with full GTK2 support. Does it (will it) require manual installation of XQuartz first?
ChrisA
I think I have a fix for the compile problem on OSX. I should be able to get something committed later today.
I got my Windows build VM up and running so hopefully will have time to test on Windows tomorrow.
It appears that the GTK shipped with homebrew uses the GDK-quartz implementation. I'm not sure if that means the GTK they ship is Quartz or X11. If I get some time I'll take a look.
To get a truly all-in-one installer, you'd probably need to compile against static libraries. I've done that with some of the basic prerequisites, and it's not hard if the --enable-static configure option is working. GTK is a bit more of an octopus so it would probably take more effort. And the GTK-Quartz library would need to work for what you want (I believe that it is not feature complete.).
Bill
Just rebased the rosuav/support-gdk-quartz branch onto current 8.1 (trivial since there'd been no changes to GTK2) so you'll get a forced-update warning when you grab this.
I would *love* to see an easy way to get Pike installed on a Mac with full GTK2 support. Does it (will it) require manual installation of XQuartz first?
ChrisA
Looks like there are some X11isms in the source code as well (such as use of GDK_DISPLAY() on non-NT systems) that will need to be dealt with. I may take a look at them at some point if no one else gets to it first.
Bill
On 2017-03-22 09:51, Chris Angelico wrote:
Just rebased the rosuav/support-gdk-quartz branch onto current 8.1 (trivial since there'd been no changes to GTK2) so you'll get a forced-update warning when you grab this.
I would *love* to see an easy way to get Pike installed on a Mac with full GTK2 support. Does it (will it) require manual installation of XQuartz first?
ChrisA
On Thu, Mar 23, 2017 at 8:06 AM, H William Wellliver III william@welliver.org wrote:
Looks like there are some X11isms in the source code as well (such as use of GDK_DISPLAY() on non-NT systems) that will need to be dealt with. I may take a look at them at some point if no one else gets to it first.
Bill
I'd be happy to look into it if I could test on Windows. But the last time I tried to set up a Windows VM for building Pike, I got massively tangled and lost (partly because it's been well over a decade since I did any major C/C++ dev on Windows).
ChrisA
Just rebased the rosuav/support-gdk-quartz branch onto current 8.1 (trivial since there'd been no changes to GTK2) so you'll get a forced-update warning when you grab this.
I don't know anything about building GTK2, but there is a change in behaviour in your patch. Before it on Windows gdk/gdkwin32.h would always be included, while now it will only be included if gdk/gdkx.h does not exists.
I would suggest to include all the relevant header files it can find, unless that creates a problem.
On Thu, Mar 23, 2017 at 12:51 AM, Chris Angelico rosuav@gmail.com wrote:
On Sat, Mar 18, 2017 at 3:55 AM, H William Wellliver III william@welliver.org wrote:
Thanks for taking a stab at it, Chris. I will have a look this weekend... just got a fresh OSX VM running so I can test things out pretty easily.
Getting a build attempt on Windows is possible but may take me a few days to get the build environment running on my new build machine. Stay tuned.
Just rebased the rosuav/support-gdk-quartz branch onto current 8.1 (trivial since there'd been no changes to GTK2) so you'll get a forced-update warning when you grab this.
I would *love* to see an easy way to get Pike installed on a Mac with full GTK2 support. Does it (will it) require manual installation of XQuartz first?
Hi, picking this up again. Does anyone know the status of GTK2 support on Macs? I've just been doing some debugging work with a Mac person who is unable to pull up anything in the GTK2 module. It's Pike 8.0.498 and the GTK module is empty (indices(GTK2) returns an empty array). It might be because XQuartz wasn't installed the first time that Homebrew installed Pike; if that's the issue, how can that be properly reset? ('brew uninstall pike; brew install pike' didn't change anything.)
I have no Mac to test things on, and VMs don't work properly (and are probably violations of Apple's TOS anyway)...
ChrisA
Hi Chris,
I tested out your branch and I think that in theory it should work, but in practice doesn't... some things I don't understand (which I think have more to do with the underlying autoconf macros):
1) It does 2 checks: presence of the header and usability of the header. Fair enough, but according to the config log, the usability test is run first (which fails, more on that below) and the presence test is run second. That seems backwards to me. Or maybe not, depending on if the availability test is what actually controls whether it gets used. But then, why run the presence test at all if the usability test fails?
2) The usability test fails, probably because on OSX, gdkquartz.h seems to include headers that use Objective-C syntax. We probably need to add -x objective-c on Darwin systems so that it doesn't choke on that. I haven't found a simple way to do that, as adding it to CFLAGS in the configure script does not seem to cause it to be used. That may or may not be a quirk of my build environment. Will test further and report back if I can't resolve that problem myself.
3.) More troubling, the 2 tests seem to use different gcc command line options. The usability test finds gdkquartz.h because it adds a bunch of stuff specified by pkg-config, which seems logical. The presence test only uses -I/usr/include -I/usr/X11/include (which seems pointless since my GTK isn't X11 based). Because you're using a pre-packaged test macro, I'd say some of these problems are buried in that macro, so we may have to do things the hard way.
Bill
pike-devel@lists.lysator.liu.se
-
Chris Angelico -
H William Wellliver III -
hww3 ＠ Pike developers forum -
Martin Nilsson (Coppermist) ＠ Pike (-) developers forum