Re: [31844] trunk/dports/x11/gtk2/Portfile
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway? This way it wouldn't be necessary to explain to a user why the selection "x11 and quartz" he just made is illegal. Regards, -Markus On 10.12.2007, at 01:54, ryandesign@macports.org wrote:
Revision 31844 Author ryandesign@macports.org Date 2007-12-09 16:54:17 -0800 (Sun, 09 Dec 2007) Log Messagegtk2: make +x11 the default only if +quartz has not been selected. If you want both, you can still request +x11 +quartzModified Paths trunk/dports/x11/gtk2/Portfile Diff Modified: trunk/dports/x11/gtk2/Portfile (31843 => 31844)--- trunk/ dports/x11/gtk2/Portfile 2007-12-10 00:53:23 UTC (rev 31843) +++ trunk/dports/x11/gtk2/Portfile 2007-12-10 00:54:17 UTC (rev 31844) @@ -49,7 +49,9 @@ port:render \ port:zlib -default_variants +x11 +if { ![variant_isset quartz] } { + default_variants +x11 +} pre- fetch { if { ![variant_isset quartz] && ![variant_isset x11] } { @@ -88,7 +90,7 @@ configure.args-append --with-gdktarget=quartz } - variant x11 description {Enable rendering in X11} { +variant x11 description {Enable rendering in X11 (default, if Quartz is not enabled)} { depends_lib-append \ port:xrender \ lib:libX11.6:xorg _______________________________________________ macports-changes mailing list macports-changes@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/macports-changes
--- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
I didn't think they were mutually exclusive? On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway? This way it wouldn't be necessary to explain to a user why the selection "x11 and quartz" he just made is illegal.
Regards,
-Markus
On 10.12.2007, at 01:54, ryandesign@macports.org wrote:
Revision 31844 Author ryandesign@macports.org Date 2007-12-09 16:54:17 -0800 (Sun, 09 Dec 2007) Log Messagegtk2: make +x11 the default only if +quartz has not been selected. If you want both, you can still request +x11 +quartzModified Paths trunk/dports/x11/gtk2/Portfile Diff Modified: trunk/dports/x11/gtk2/Portfile (31843 => 31844)--- trunk/ dports/x11/gtk2/Portfile 2007-12-10 00:53:23 UTC (rev 31843) +++ trunk/dports/x11/gtk2/Portfile 2007-12-10 00:54:17 UTC (rev 31844) @@ -49,7 +49,9 @@ port:render \ port:zlib -default_variants +x11 +if { ![variant_isset quartz] } { + default_variants +x11 +} pre- fetch { if { ![variant_isset quartz] && ![variant_isset x11] } { @@ -88,7 +90,7 @@ configure.args-append --with- gdktarget=quartz } -variant x11 description {Enable rendering in X11} { +variant x11 description {Enable rendering in X11 (default, if Quartz is not enabled)} { depends_lib-append \ port:xrender \ lib:libX11.6:xorg
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
I didn't think they were mutually exclusive?
"\n\nThe gtk2 port can be built and installed with support for either Quartz\n(Aqua) rendering or X11 rendering, but not both.\n\n" [1] [1] https://trac.macosforge.org/projects/macports/browser/trunk/ dports/x11/gtk2/Portfile?rev=31844
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway? This way it wouldn't be necessary to explain to a user why the selection "x11 and quartz" he just made is illegal.
Regards,
-Markus
On 10.12.2007, at 01:54, ryandesign@macports.org wrote:
Revision 31844 Author ryandesign@macports.org Date 2007-12-09 16:54:17 -0800 (Sun, 09 Dec 2007) Log Messagegtk2: make +x11 the default only if +quartz has not been selected. If you want both, you can still request +x11 +quartzModified Paths trunk/dports/x11/gtk2/Portfile Diff Modified: trunk/dports/x11/gtk2/Portfile (31843 => 31844)--- trunk/dports/x11/gtk2/Portfile 2007-12-10 00:53:23 UTC (rev 31843) +++ trunk/dports/x11/gtk2/Portfile 2007-12-10 00:54:17 UTC (rev 31844) @@ -49,7 +49,9 @@ port:render \ port:zlib - default_variants +x11 +if { ![variant_isset quartz] } { + default_variants +x11 +} pre-fetch { if { ![variant_isset quartz] && ![variant_isset x11] } { @@ -88,7 +90,7 @@ configure.args- append --with-gdktarget=quartz } -variant x11 description {Enable rendering in X11} { +variant x11 description {Enable rendering in X11 (default, if Quartz is not enabled)} { depends_lib- append \ port:xrender \ lib:libX11.6:xorg
--- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/
On Dec 10, 2007, at 08:43, Weissmann Markus wrote:
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway?
Since there is a choice to be made for x11 support or quartz support, I think it makes sense to list both of these as variants. The port should (and now does) ensure that exactly one of these is selected at all times.
This way it wouldn't be necessary to explain to a user why the selection "x11 and quartz" he just made is illegal.
I didn't think they were mutually exclusive?
"\n\nThe gtk2 port can be built and installed with support for either Quartz\n(Aqua) rendering or X11 rendering, but not both.\n \n" [1]
[1] https://trac.macosforge.org/projects/macports/browser/trunk/ dports/x11/gtk2/Portfile?rev=31844
Oh hey, so it is. I marked the +x11 and +quartz variants as conflicting with one another in r31870. That should do it.
On 10.12.2007, at 18:27, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:43, Weissmann Markus wrote:
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway?
Since there is a choice to be made for x11 support or quartz support, I think it makes sense to list both of these as variants. The port should (and now does) ensure that exactly one of these is selected at all times.
well, I prefer to not making this a philosophical problem: With one variant, you get two different installations, with two variants, you get four. In this case (gtk2), two of the four variants are "errors" and are then fixed (with the defaults variant) or with a user warning. I think it would be better to eliminate the problem altogether then trying to fix it's effects.
This way it wouldn't be necessary to explain to a user why the selection "x11 and quartz" he just made is illegal.
I didn't think they were mutually exclusive?
"\n\nThe gtk2 port can be built and installed with support for either Quartz\n(Aqua) rendering or X11 rendering, but not both.\n \n" [1]
[1] https://trac.macosforge.org/projects/macports/browser/trunk/ dports/x11/gtk2/Portfile?rev=31844
Oh hey, so it is. I marked the +x11 and +quartz variants as conflicting with one another in r31870. That should do it.
s.o. Regards, -Markus --- Dipl. Inf. (FH) Markus W. Weissmann http://www.mweissmann.de/ http://www.macports.org/
On Dec 10, 2007, at 11:42, Weissmann Markus wrote:
On 10.12.2007, at 18:27, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:43, Weissmann Markus wrote:
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway?
Since there is a choice to be made for x11 support or quartz support, I think it makes sense to list both of these as variants. The port should (and now does) ensure that exactly one of these is selected at all times.
well, I prefer to not making this a philosophical problem: With one variant, you get two different installations, with two variants, you get four.
That's certainly one way to use variants. That's the "checkbox" way.
In this case (gtk2), two of the four variants are "errors" and are then fixed (with the defaults variant) or with a user warning. I think it would be better to eliminate the problem altogether then trying to fix it's effects.
I prefer to think of this as the "radio button" way. It's perfectly acceptable to mark variants as conflicting with one another. That's why the "conflicts" keyword exists. If I were writing a GUI to install ports, I'd make it so variants were represented as checkboxes, except when the "conflicts" keyword is encountered, which turns those variants into radio buttons. See also my minivmac portfile, which has 5 variants for selecting which ancient Mac model you want it to emulate. Exactly one variant must be selected. All the variants conflict with one another, and one of them is the default: $ port variants minivmac minivmac has the variants: mac128k: Emulate a Macintosh with 128K RAM and 2 drives mac512k: Emulate a Macintosh 512K with 512K RAM and 2 drives mac512ke: Emulate a Macintosh 512Ke with 512K RAM and 6 drives macplus: Emulate a Macintosh Plus with 4 MB RAM and 6 drives (default) macse: Emulate a Macintosh SE with 4 MB RAM and 6 drives $
On Dec 10, 2007, at 6:50 PM, Ryan Schmidt wrote:
On Dec 10, 2007, at 11:42, Weissmann Markus wrote:
On 10.12.2007, at 18:27, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:43, Weissmann Markus wrote:
On 10.12.2007, at 15:23, Ryan Schmidt wrote:
On Dec 10, 2007, at 08:16, Weissmann Markus wrote:
Hmmm... wouldn't it be much cleaner and easier to only have one variant "quartz" as "quartz" and "x11" are mutually exclusive anyway?
Since there is a choice to be made for x11 support or quartz support, I think it makes sense to list both of these as variants. The port should (and now does) ensure that exactly one of these is selected at all times.
well, I prefer to not making this a philosophical problem: With one variant, you get two different installations, with two variants, you get four.
That's certainly one way to use variants. That's the "checkbox" way.
In this case (gtk2), two of the four variants are "errors" and are then fixed (with the defaults variant) or with a user warning. I think it would be better to eliminate the problem altogether then trying to fix it's effects.
I prefer to think of this as the "radio button" way. It's perfectly acceptable to mark variants as conflicting with one another. That's why the "conflicts" keyword exists. If I were writing a GUI to install ports, I'd make it so variants were represented as checkboxes, except when the "conflicts" keyword is encountered, which turns those variants into radio buttons.
See also my minivmac portfile, which has 5 variants for selecting which ancient Mac model you want it to emulate. Exactly one variant must be selected. All the variants conflict with one another, and one of them is the default:
$ port variants minivmac minivmac has the variants: mac128k: Emulate a Macintosh with 128K RAM and 2 drives mac512k: Emulate a Macintosh 512K with 512K RAM and 2 drives mac512ke: Emulate a Macintosh 512Ke with 512K RAM and 6 drives macplus: Emulate a Macintosh Plus with 4 MB RAM and 6 drives (default) macse: Emulate a Macintosh SE with 4 MB RAM and 6 drives $
Excellent example! Most often variants are used because of shortcomings of software: You have to decide at build-time because the software doesn't let you decide at run-time (or via config-file, etc.). This is all an optimization problem where we have different goals, like: max. functionality, min. space, min. compile-time, min. download volume, etc., etc. We have to decide which ONE of these is our primary goal. And so far the consent has been to get max. functionality. Example: minivmac makes you decide at compile-time which mac you want to emulate. Solution min. compile time: Variant for each mode. Solution max. functionality: Compile all of them and install them side by side (I'm sure this is possible) With each variant a port has, the max. functionality value suffers: The min. compile time solution of minivmac only offers 20% of the functionality of the max. functionality version (for each variant). Also the reproducibility suffers with each variant: Assume you got a bug report for A failing which requires library B. If B has no variants, you can reproduce the error on your machine (hopefully). If B has two variants, you may have to test three times till you reproduce it. And if B requires C which has another two variants you get 9 possible installations to look into. And it is getting worse exponentially with the dependency tree depth. Therefore variants are for experienced users only and people who just want stuff to work shouldn't have to select a single variant. The default installation should provide the maximum reasonable*) functionality. Try to avoid variants like the plague. If the software forces you to make a choice, let the default choice be the most reasonable one. If you have to force the user to make a choice, you're most probably doing something wrong: Either install both choices (e.g. minivmac - see above) or split the ports (e.g. openssl and openssl97). Don't think of variants as cool knobs to fiddle around but as poor workarounds for shortcomings of the software. Of course variants can be useful if you cannot fix the software or for features with minimal benefit which are extremely expensive (e.g. support for gtk1, gtk2, motif, wxWidgets, Cocoa, QT AND SDL), for switches that turn on experimental stuff, etc. Regards, -Markus *) This means that if your port supports a functionality that only three people on this planet might use and this feature conflicts with a common one, you should move the uncommon one to a variant. E.g. if the graphics front end supports gtk2 and motif, well, forget about motif or put it into a variant for the huge crowd who loves motif. -- Dipl. Inf. (FH) Markus W. Weissmann http://www.macports.org/ http://www.mweissmann.de/
participants (3)
-
Markus Weissmann
-
Ryan Schmidt
-
Weissmann Markus