+x11, and +quartz variants (or a dangerous idea)
I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant: +quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11 Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used. Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged. Background: I have removed X11 from my laptop and am building (albeit slowly) and using applications that I used to run under X11 under Aqua or am using an Aqua-based (roughly) equivilent application. This has revealed a number of instances of ports assuming that X11 is installed on a Mac OS X box, when that assumition is or should be false, such as when the upstream project is supporting Quartz-only builds, or when the project actually only really cares if GTK+ is installed, but the port hauls in X-based dependencies anyway. Some ports even build both the X11 and Quartz libraries for the port, but then only advertize to subsequent and dependent builds only the Quartz library. While working through this, I realized that we should assume that X11 is not available on a machine and that we should re-gin our ports to match that assumption. Right now the assumption for most ports is that X11 is installed on a machine, and that users would prefer items that provide both X11 and Quartz should always provide X11 versions and should only maybe provide Quartz versions. Randall Wood randall.h.wood@alexandriasoftware.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Hi Randall, On Tiger, I would've agreed with you. On Leopard, X11 is installed by default, so I don't see a lot of value in assuming it is *not* present. -- Ernie P. On Nov 30, 2007, at 3:10 AM, Randall Wood wrote:
I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant:
+quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11
Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used.
Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged.
Background:
I have removed X11 from my laptop and am building (albeit slowly) and using applications that I used to run under X11 under Aqua or am using an Aqua-based (roughly) equivilent application. This has revealed a number of instances of ports assuming that X11 is installed on a Mac OS X box, when that assumition is or should be false, such as when the upstream project is supporting Quartz-only builds, or when the project actually only really cares if GTK+ is installed, but the port hauls in X-based dependencies anyway. Some ports even build both the X11 and Quartz libraries for the port, but then only advertize to subsequent and dependent builds only the Quartz library.
While working through this, I realized that we should assume that X11 is not available on a machine and that we should re-gin our ports to match that assumption. Right now the assumption for most ports is that X11 is installed on a machine, and that users would prefer items that provide both X11 and Quartz should always provide X11 versions and should only maybe provide Quartz versions.
Randall Wood randall.h.wood@alexandriasoftware.com http://shyramblings.blogspot.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy." _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-dev
Le 07-11-30 à 14:23, Ernest Prabhakar a écrit :
Hi Randall,
On Tiger, I would've agreed with you. On Leopard, X11 is installed by default, so I don't see a lot of value in assuming it is *not* present.
-- Ernie P.
On Nov 30, 2007, at 3:10 AM, Randall Wood wrote:
I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant:
+quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11
Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used.
Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged.
Background:
I have removed X11 from my laptop and am building (albeit slowly) and using applications that I used to run under X11 under Aqua or am using an Aqua-based (roughly) equivilent application. This has revealed a number of instances of ports assuming that X11 is installed on a Mac OS X box, when that assumition is or should be false, such as when the upstream project is supporting Quartz-only builds, or when the project actually only really cares if GTK+ is installed, but the port hauls in X-based dependencies anyway. Some ports even build both the X11 and Quartz libraries for the port, but then only advertize to subsequent and dependent builds only the Quartz library.
While working through this, I realized that we should assume that X11 is not available on a machine and that we should re-gin our ports to match that assumption. Right now the assumption for most ports is that X11 is installed on a machine, and that users would prefer items that provide both X11 and Quartz should always provide X11 versions and should only maybe provide Quartz versions.
I would rather say we are assuming the user wants X11 flavor over quartz. Which is, at the moment, a good presumption for gtk+ and a more questionnable one for Qt. yves
On Nov 30, 2007, at 05:10, Randall Wood wrote:
I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant:
+quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11
Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used.
Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged.
I wouldn't make this generalization. There are ports, like ImageMagick, that have a +no_x11 variant, which I believe should continue to have them. ImageMagick can build with support for some X11 things, or not. By default, we want to build the most featureful software possible, so X11 support is on by default. Users who do not wish this support can use the +no_x11 variant. I'm not aware of any Quartz support in ImageMagick. Unless you would like to redefine our default installation goals to no longer be "most featureful" but instead be "most featureful excluding X11 things". I'm not saying we should or should not redefine this, just point out what our current status is, and that you seem to be proposing a change to that. Actually, I guess our current guidelines are to build a port to be the most featureful while not including huge libraries as dependencies which most users won't want. Thus far, I think we've had an unspoken agreement that the X11 features are useful, and indeed our installation docs require the user to install X11 and the X11SDK. I guess you're proposing a change to that as well.
On 12/1/07, Ryan Schmidt <ryandesign@macports.org> wrote:
On Nov 30, 2007, at 05:10, Randall Wood wrote:
I would like to suggest that the variants +quartz and +x11 should be supported where relevant, eliminating the use of the +no_x11 variant:
+quartz Enable building the port to render graphics using the quartz engine and aqua user interface +x11 Enable building the port to use X11
Furthermore, I would like to suggest that these variants should never be default variants and that we should modify the macports base to recognize that a port has these variants and if neither is selected (either at the command line or in variants.conf) that an error message should be displayed explaining that the port may be installed with either: +quartz, +x11, or +quartz+x11, although some ports may result in unpredicatable behavior if +quartz+x11 is used.
Furthermore, I would like to suggest that the +no_x11 variant and the +no_quartz (if it is used at all) variants should be actively discouraged.
I wouldn't make this generalization. There are ports, like ImageMagick, that have a +no_x11 variant, which I believe should continue to have them. ImageMagick can build with support for some X11 things, or not. By default, we want to build the most featureful software possible, so X11 support is on by default. Users who do not wish this support can use the +no_x11 variant. I'm not aware of any Quartz support in ImageMagick.
Unless you would like to redefine our default installation goals to no longer be "most featureful" but instead be "most featureful excluding X11 things". I'm not saying we should or should not redefine this, just point out what our current status is, and that you seem to be proposing a change to that.
Actually, I guess our current guidelines are to build a port to be the most featureful while not including huge libraries as dependencies which most users won't want. Thus far, I think we've had an unspoken agreement that the X11 features are useful, and indeed our installation docs require the user to install X11 and the X11SDK. I guess you're proposing a change to that as well.
This is not a case of selecting features, but of having to make *mutually exclusive choices* between the Aqua (quartz rendering) and X11 user interfaces. In this case, I think we should make the default behavior be Aqua, but I am aware that pushing that now will break what already works during an upgrade, so I have made the default behavior to fail without explicit instructions from the user. -- Randall Wood randall.h.wood@alexandriasoftware.com "The rules are simple: The ball is round. The game lasts 90 minutes. All the rest is just philosophy."
Citando Randall Wood :
On 12/1/07, Ryan Schmidt <ryandesign@macports.org> wrote:
I wouldn't make this generalization. There are ports, like ImageMagick, that have a +no_x11 variant, which I believe should continue to have them. ImageMagick can build with support for some X11 things, or not. By default, we want to build the most featureful software possible, so X11 support is on by default. Users who do not wish this support can use the +no_x11 variant. I'm not aware of any Quartz support in ImageMagick.
Unless you would like to redefine our default installation goals to no longer be "most featureful" but instead be "most featureful excluding X11 things". I'm not saying we should or should not redefine this, just point out what our current status is, and that you seem to be proposing a change to that.
Actually, I guess our current guidelines are to build a port to be the most featureful while not including huge libraries as dependencies which most users won't want. Thus far, I think we've had an unspoken agreement that the X11 features are useful, and indeed our installation docs require the user to install X11 and the X11SDK. I guess you're proposing a change to that as well.
This is not a case of selecting features, but of having to make *mutually exclusive choices* between the Aqua (quartz rendering) and X11 user interfaces. In this case, I think we should make the default behavior be Aqua, but I am aware that pushing that now will break what already works during an upgrade, so I have made the default behavior to fail without explicit instructions from the user.
This choice between aqua and x11 is only sensible for ports depending on gtk. ImageMagick's display, teTeX's xdvi and most ports depending on X11 have no quartz backend. I don't know about gtk (the number of dependencies made me avoid gtk on osx), I'm not sure about qt (qt-mac and qt-x11 seem to provide the same things and ports depending on qt seem to be able to work in both cases), but for other things +no_x11 is often the most sensible variant to provide. As for gimp and other gtk progs, isn't the best way to do to have a gimp-app and gimp-x port that depend on two gtk2 ports (gtk2-quartz and gtk2-x) as vim-app vs vim +gtk or carbon-emacs vs emacs? Probably the most time consuming for the maintainers though as it means a lot of ports that become twice a lot of ports (but half as many variants to test and no black-variant-magick dependency to check). Emmanuel
participants (5)
-
Emmanuel Hainry
-
Ernest Prabhakar
-
Randall Wood
-
Ryan Schmidt
-
Yves de Champlain