gobject_introspection portgroup

[ryandesign (Ryan Carsten Schmidt)]

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.

[dbevans (David B. Evans)]

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.

[dbevans (David B. Evans)]

I would add that, at least for GNOME ports,

gobject_introspection yes

would be a more appropriate default.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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 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.

[dbevans (David B. Evans)]

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.

[dbevans (David B. Evans)]

Replying to ryandesign@…:

Replying to 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?

[ryandesign (Ryan Carsten Schmidt)]

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.

[dbevans (David B. Evans)]

Replying to 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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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.

[ryandesign (Ryan Carsten Schmidt)]

Replying to 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. not sure why.

[ryandesign (Ryan Carsten Schmidt)]

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.

[cooljeanius (Eric Gallager)]

Cc Me!

[ryandesign (Ryan Carsten Schmidt)]

Dave committed the portgroup in r131817.

[dbevans (David B. Evans)]

Thanks for this suggestion, Ryan.

I'll be updating the dependencies of gnome3-core and gnome3-apps this week (including gstreamer1*) as well as my other ports that use gobject-introspection. I'd appreciate it if you would update the ports that you maintain, particularly, pango and pango-devel.

Anything else is up for grabs.