[MacPorts] #45263: gobject_introspection portgroup
#45263: gobject_introspection portgroup --------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: new Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Keywords: haspatch | Port: --------------------------+---------------------- Instead of adding the same configure and build arguments and build and library dependencies to each port that uses gobject introspection, what would you think about using a portgroup? This would simplify the ports and avoid the current problem of forgetting to add code needed for systems or scenarios you didn't test. With this portgroup, you would add {{{ PortGroup gobject_introspection 1.0 }}} near the top of the portgroup, then add {{{ gobject_introspection yes }}} after dependencies are set. You would no longer need to manually add `port:gobject-introspection` to `depends_lib`, add `--enable-introspection` to `configure.args`, write a `pre-build` block adding `CC` to `build.args`, nor write a `platform darwin 8` block adding `port:gmake` to `depends_build` and setting `build.cmd`. See attached proposed portgroup and sample port modifications. -- Ticket URL: <https://trac.macports.org/ticket/45263> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Changes (by devans@…): * status: new => assigned Comment: Thanks for this suggestion, Ryan. This is one of a number of issues that I think could be included in a broader gnome Port Group. Will review and incorporate these changes during the GNOME 3.15 development cycle. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:1> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by devans@…): I would add that, at least for GNOME ports, {{{ gobject_introspection yes }}} would be a more appropriate default. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:2> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by ryandesign@…): Replying to [comment:1 devans@…]:
This is one of a number of issues that I think could be included in a broader gnome Port Group. Will review and incorporate these changes during the GNOME 3.15 development cycle.
Sounds good. Thanks. What else were you considering for the gnome portgroup, and is there anything you need help with? Replying to [comment:2 devans@…]:
I would add that, at least for GNOME ports, {{{ gobject_introspection yes }}} would be a more appropriate default.
I considered that, but was trying to learn my lesson from the app portgroup, in which I turned its functionality on by default. This turned out to be inconvenient in situations where some subports or variants in a portfile wanted the feature and some did not. Consider for example the goffice port. The main goffice port wants introspection, but the goffice08 subport does not. Additionally, if the portgroup were to enable introspection the moment it is included, as you suggest, this would mean all ports that use it would need to ensure they use `depends_lib-append` instead of overwriting `depends_lib`, and `depends_build-append` instead of overwriting `depends_build`. This kind of thing is easily forgotten and will lead to more problems to be debugged later. If instead we simply require that `gobject_introspection yes` is called after the dependencies have been added, then we avoid those problems. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:3> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by devans@…): I see your point. Not so easy. Another gotcha is that ports that use muniversal need special handling to get the proper compiler set for introspection. gegl is an example. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:4> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by devans@…): Replying to [comment:3 ryandesign@…]:
Replying to [comment:1 devans@…]:
This is one of a number of issues that I think could be included in a broader gnome Port Group. Will review and incorporate these changes during the GNOME 3.15 development cycle.
Sounds good. Thanks. What else were you considering for the gnome portgroup, and is there anything you need help with?
Largely, handling of post-activate, post-deactivate handling based on what type of resources are installed and handling the issue of +quartz variants where the ports will accomodate them. To do the latter more easily, I have been thinking that cairo and gtk3, both of which now support building multiple backends concurrently, should perhaps use subports rather than variants to indicate which backends to include. I think this would simplify variant handling. Would this work for cairo? That is, have cairo itself install a small common set of backends and have subports for x11 and quartz? -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:5> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by ryandesign@…): At one time I thought all ports offering quartz and x11 variants should use subports instead. But a different suggestion is that cairo and pango could just enable both quartz and x11 support all the time. This is #44414. The cairo and pango build systems used to force you to just use one or the other, but since some time that hasn't been the case anymore. If we're lucky, just enabling both interfaces all the time won't cause problems. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:6> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by devans@…): Replying to [comment:6 ryandesign@…]:
At one time I thought all ports offering quartz and x11 variants should use subports instead.
But a different suggestion is that cairo and pango could just enable both quartz and x11 support all the time. This is #44414. The cairo and pango build systems used to force you to just use one or the other, but since some time that hasn't been the case anymore. If we're lucky, just enabling both interfaces all the time won't cause problems.
In this case, I would vote to drop cairo's +x11 +quartz variants as well. The point would be to reduce variant complexity. In the gtk3 case as mentioned in #44414 since 3.10 gtk3 has been able to build all gdk backends simulanteously. This includes x11, quartz, broadway (html5), and wayland (not likely to be much use on Macs?). GNOME ports are gradually moving to support the multiple backends, although X11 is still the only backend that is supported throughout. Multiple print backends are also possible. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:7> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by ryandesign@…): Replying to [comment:4 devans@…]:
Another gotcha is that ports that use muniversal need special handling to get the proper compiler set for introspection. gegl is an example.
True. Attached a new version of the portgroup to handle that, and a diff for gegl. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:8> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by ryandesign@…): Replying to [comment:8 ryandesign@…]:
Attached a new version of the portgroup to handle that,
Doesn't work, because the muniversal portgroup prevents ports from using pre- and post- -configure and -build blocks. That needs to be fixed. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:9> MacPorts <http://www.macports.org/> Ports system for OS X
#45263: gobject_introspection portgroup ---------------------------+---------------------- Reporter: ryandesign@… | Owner: devans@… Type: enhancement | Status: assigned Priority: Normal | Milestone: Component: ports | Version: 2.3.99 Resolution: | Keywords: haspatch Port: | ---------------------------+---------------------- Comment (by ryandesign@…): Ok, it was actually simple. The muniversal portgroup handles `merger_build_args` as a variable, rather than as an option as one would expect, which means it has to be declared as `global`. Fixed version of portgroup attached. -- Ticket URL: <https://trac.macports.org/ticket/45263#comment:10> MacPorts <http://www.macports.org/> Ports system for OS X
participants (1)
-
MacPorts