Changes between Initial Version and Version 1 of Ticket #53911, comment 4
- Timestamp:
- Apr 4, 2017, 1:36:25 PM (7 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #53911, comment 4
initial v1 5 5 Essentially, I implemented the changes in autoconf.ac and Makefile.am, then had autotools re-generate the affected files (config.h.in, configure, Makefile.in) and spun that off in a different patchfile that can be applied without having to use autoreconf. 6 6 7 I have also added x11 and quartz variants to glib. They do not really do anything X11- or Quartz-related per se, but switch to the generic (freedesktop-based) appinfo implementation for X11 builds and stick to the native (appbundle-based) implementation for Quartz builds. Needless to say, either maintainers or users have to make sure that `gtk3` and `glib2-devel` are built with the same variants, but I think that's fine. 7 I have also added x11 and quartz variants to glib. They do not really do anything X11- or Quartz-related per se, but switch to the generic (freedesktop-based) appinfo implementation for X11 builds and stick to the native (appbundle-based) implementation for Quartz builds. Needless to say, either maintainers or users have to make sure that `gtk3` and `glib2-devel` are built with the same variants, but I think that's fine. (To make that clear: upstream's master branch currently disables .desktop parsing support on OS X pretty much, as far as I can tell. We'll need to revert this in a sane manner so that our X11 builds can continue to use it, while only messing with it for quartz builds. It's better to do that in the upstream package I'd say.) 8 8 9 9 Regarding `gtk3`, I'm only using the mentioned upstream patch for +quartz builds. This is because we actually *want* to use the freedesktop-based implementation for +x11 builds. This also means that we will have to work with upstream to make sure that once that patch is part of a new official GTK+ release, switching between these implementations is possible at build time.