On Mar 27, 2009, at 16:18, Travis Griggs wrote:
Ryan Schmidt (the maintainer of the Cairo port) asked me to lobby
the list for feedback on an issue I recently ran aground of. Cairo
can be built with multiple backends. Once upon a time, the default
configuration caused only the xlib backend to be built. You had to
take extra steps to get the quartz backend built. And then that
changed, and BOTH backends were turned on by default. Ryan recently
changed it back to the old way, so that quartz requires extra
configuration to work. I've lobbied him to revert it (I should take
a moment to thank him for providing the port in the first place,
thank you very much Ryan) so that quartz is on by default. In fact
I might go so far as to say xlib does not need to be turned on
unless told to be, but that's because for MY uses, I just need quartz.
To provide some background:
The cairo port initially did not have quartz enabled because the
cairo software initially did not have any quartz support to enable.
Then cairo added experimental quartz support. Since it was
experimental, I did not enable it by default in the port. More
importantly, you had to choose between quartz and xlib; you could not
have both at once. So I made it a variant.
Once the experimental label was removed from cairo's quartz support
and it was possible to have quartz and xlib interfaces active at the
same time, I changed the port to always enable quartz, and removed
the variant. It was explained to me that each program that wants to
use cairo must write separate code for each backend they want to
support -- separate code for cairo xlib vs. cairo quartz. So I
figured enabling quartz by default would only help, since programs
not written to use it wouldn't be affected.
Then I found that pango has code that uses cairo quartz if available.
pango + cairo is a very common combination. Programs that use pango
are using cairo indirectly. And it seems that programs that use pango
don't need to use special pango calls to get pango's quartz features.
They happen automatically -- which can cause problems, and did, for
graphviz and allegedly all gtk2 apps; see:
https://mailman.research.att.com/pipermail/graphviz-interest/
2009q1/006035.html
http://trac.macports.org/ticket/15626
http://trac.macports.org/ticket/16778
So my impression of quartz support in cairo and pango now is that it
has the potential to break software. Therefore I think it's wise to
require users to actively request it, via a variant.
There's also the matter of precedent. We have 17 ports today that
have a variant called +quartz. We have 0 ports with a variant called
+no_quartz. So in all ports that offer optional quartz support today,
it is an opt-in feature, not opt-out.
There is one exception currently: port squeak uses this line to
enable +quartz all the time:
default_variants +quartz
It should not do so in this way, however, since it is cumbersome for
users who want to disable it to do so, because of:
http://trac.macports.org/ticket/2377
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
