Cairo default configuration

[Ryan Schmidt]

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