Hi,

GTk4 currently requires a newer OS version that I'm running so I decided to do 
some simple testing with GTk3+quartz. I already had a slightly customised 
version of the port (and port:libepoxy), so it was trivial and fast to add 
`libepoxy-quartz` and `gtk3-quartz` subports that hardwire the +quartz variant 
and install into $prefix/libexec/GTQuartz . I have too many GTk3 ports 
installed that I want to be able to use from a remote X11 server so the current 
design whereby you'd have to deactivate the +x11 builds of all relevant ports 
in order to use the +quartz variant of even a single port is just too 
cumbersome.

I get the impression that meson isn't really designed for this sort of thing 
(you need to prepend the subprefix to $PKG_CONFIG_PATH so the "hidden" versions 
of dependencies are found?!) but that aspect worked out for `port:gtk3-quartz` 
finding `port:libepoxy-quartz` without having to set a build conflict.

The demo applications run and with a valid event loop and skeleton toplevel 
menu, but they don't show a window at all and the "about" dialog only shows a 
titlebar. No glib error messages whatsoever.

Does this ring a bell for anyone, iow, is this a known symptom with a known 
cause/solution? 

FWIW, I replaced the `[variant_isset quartz]` calls with 
`[variant_isset:quartz]` (idem for x11), where
{{{
proc variant_isset:quartz {} {
    global subport name
    return [expr {[variant_isset quartz] || ${subport} eq "${name}-quartz"}]
}

proc variant_isset:x11 {} {
    global subport
    return [expr {[variant_exists x11] && [variant_isset x11]}]
}
}}}

so changes to the Portfile and risk of overlooking something could be minimal.

Thanks,
R.



Reply via email to