On Apr 14, 2009, at 18:49, Jeremy Huddleston wrote:
I think it might be wise to create a list of such volatile variants
(system_x11, universal, no_x11, etc) and mention them to users in
the install guide, so they can make decisions about them before
it's too late.
That might be a good idea. Could you file a documentation ticket for
that? It would also be good to describe these variants in the Guide
and provide guidance for their use.
Also, this brings up a point that has been bothering me for a
while. Why do we have so many variants for what should really be a
single binary decision: +x11, +no_x11, +quartz, +no_quartz, +aqua
As David said, it's not necessarily a binary decision. For some
ports, X11 and Quartz interfaces conflict, but for others, they
don't. For example cairo by default builds with X11 support but not
Quartz support. If you want both, you use just +quartz. If you want
Quartz but no X11 support, you use +quartz +no_x11. If you want some
undefined build that contains support for no graphics output at all,
you use just +no_x11. :) Hmm, maybe I need to make that impossible.
Our tradition in MacPorts has been to enable X11 support by default,
hence usually there is no +x11 variant, but there might be a +no_x11
variant. This was just a natural application of the general principle
that *any* feature should be enabled by default, to provide the most
full-featured build possible by default, and provide +no_whatever
variants to disable them if necessary. Some ports decided X11 support
should be off by default. Maybe they have good reasons for that.
Maybe they don't and should be changed.
+quartz provides the ability to use Mac OS X native drawing either in
addition to or instead of X11 rendering, depending on the port (which
depends on the abilities of the ported software).
No port has a variant +no_quartz.
You're probably right that +aqua could be renamed to +quartz for
consistency. Though they may not necessarily mean the same thing. I
think the original intention may have been for +quartz to use Mac OS
X graphics rendering routines and +aqua to install a Mac OS X
application bundle. These may go hand in hand, or they may not.
Existing ports also might not necessarily follow this convention.
_______________________________________________
macports-dev mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-dev
