Re: [27427] trunk/dports/graphics/gimp2/Portfile
source_changes@macosforge.org wrote:
Revision 27427 <http://trac.macosforge.org/projects/macports/changeset/27427> Author yves@macports.org Date 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) [...] +variant without_python conflicts python24 { + depends_lib-delete port:py25-gtk + configure.env-delete PYTHON=${prefix}/bin/python2.5 + configure.args-append --disable-python +} +
I don't like this name without_*. I would prefer a variant +python and setting default_variants +python So if someone does not want python he/she can overwrite that using port install gimp2 -python What do you think about that? Rainer
Le 07-08-03 à 12:47, Rainer Müller a écrit :
source_changes@macosforge.org wrote:
Revision 27427 <http://trac.macosforge.org/projects/macports/changeset/ 27427> Author yves@macports.org Date 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) [...] +variant without_python conflicts python24 { + depends_lib-delete port:py25-gtk + configure.env-delete PYTHON=${prefix}/bin/python2.5 + configure.args-append --disable-python +} +
I don't like this name without_*. I would prefer a variant +python and setting default_variants +python
So if someone does not want python he/she can overwrite that using port install gimp2 -python
What do you think about that?
For my part, I don't like default variants ... I think MacPorts really needs some sort of variants naming guidelines. yves
I don't like default variants either (except for those system-wide ones like darwin_8). Does "port info <pkg>" show default variants? If it does not, it's not a good idea to use default variants. Best Regards, Xin Liu On 8/3/07, Rainer Müller <raimue@macports.org> wrote:
source_changes@macosforge.org wrote:
Revision 27427 <http://trac.macosforge.org/projects/macports/changeset/27427> Author yves@macports.org Date 2007-08-03 09:30:45 -0700 (Fri, 03 Aug 2007) [...] +variant without_python conflicts python24 { + depends_lib-delete port:py25-gtk + configure.env-delete PYTHON=${prefix}/bin/python2.5 + configure.args-append --disable-python +} +
I don't like this name without_*. I would prefer a variant +python and setting default_variants +python
So if someone does not want python he/she can overwrite that using port install gimp2 -python
What do you think about that?
Rainer
Xin Liu wrote:
I don't like default variants either (except for those system-wide ones like darwin_8). Does "port info <pkg>" show default variants? If it does not, it's not a good idea to use default variants.
It could be changed to do so :-) I don't like the syntax +without_foo as it reads "with without foo" for me. Why do we have that +/- syntax if we don't use it? The syntax is straightforward as + selects and - deselects a feature provided by a variant. I like that more than deselecting variants with +no_foo or +without_foo And as Yves said, variant naming is totally inconsistent at the moment. There are variants which do the same but are named differently as +no_bdb or +without_bdb. As far as I could find there are the following prefixes: with_ without_ enable_ disable_ no_ If the naming were "correct" we could also make more use of variants.conf. Someone could set -bdb to never include BDB if it can be left out. Or +x11 to always build with support for x11. I would like that more than setting +no_bdb. But as said, port info should show default variants. And they could be also marked (with a star or something) in port variants. Rainer
On Aug 3, 2007, at 1:45 PM, Rainer Müller wrote:
I don't like the syntax +without_foo as it reads "with without foo" for me. Why do we have that +/- syntax if we don't use it?
We don't use it because it's currently broken (ie, the -variants that are selected aren't stored, so when you go to upgrade the port, it doesn't keep the same variant selection. Meanwhile, the +variants are stored, so things 'work' when you do an upgrade).
But as said, port info should show default variants. And they could be also marked (with a star or something) in port variants.
That seems like a good idea. You want to submit a patch? :) -- Daniel J. Luke +========================================================+ | *---------------- dluke@geeklair.net ----------------* | | *-------------- http://www.geeklair.net -------------* | +========================================================+ | Opinions expressed are mine and do not necessarily | | reflect the opinions of my employer. | +========================================================+
Le 07-08-03 à 14:48, Daniel J. Luke a écrit :
On Aug 3, 2007, at 1:45 PM, Rainer Müller wrote:
I don't like the syntax +without_foo as it reads "with without foo" for me. Why do we have that +/- syntax if we don't use it?
We don't use it because it's currently broken (ie, the -variants that are selected aren't stored, so when you go to upgrade the port, it doesn't keep the same variant selection. Meanwhile, the +variants are stored, so things 'work' when you do an upgrade).
But as said, port info should show default variants. And they could be also marked (with a star or something) in port variants.
That seems like a good idea. You want to submit a patch? :)
There is something else. Right now, gimp2 has python24 without_gnome without_python To follow your (rainer's) logic, gimp2 would then have python24 python25 gnome with gnome and python25 both as default. Is this possible with the current implementation? Next, let's say I want python24, then I will have to do port install gimp2 +python24 +gnome If I don't want gnome I'll have to do port install gimp2 +python25 The point is that internals and default become less transparant and more complex for the user. Many might do "-gnome" and miss python or "python24" and miss gnome ... That is the problem with default variants. yves
On Aug 3, 2007, at 12:45, Rainer Müller wrote:
But as said, port info should show default variants. And they could be also marked (with a star or something) in port variants.
I have taken to using the variant description to indicate whether a variant is the default, among other things. See "port variants minivmac" and "port variants pdfkt".
Yves de Champlain wrote:
There is something else.
Right now, gimp2 has
python24 without_gnome without_python
To follow your (rainer's) logic, gimp2 would then have
python24 python25 gnome
with gnome and python25 both as default.
Is this possible with the current implementation?
Next, let's say I want python24, then I will have to do
port install gimp2 +python24 +gnome
No, you would have to do port install gimp2 -python25 +python24 We don't want python25, but we want to use python24 instead. python25 needs to be explicitely deselected since both would be conflicting. But +gnome would be not affected and is still selected automatically from default_variants.
If I don't want gnome I'll have to do
port install gimp2 +python25
No, it should be port install gimp2 -gnome Which would still install python25, as this wasn't overwritten from default_variants.
The point is that internals and default become less transparant and more complex for the user.
I admit it is a little bit more complex to deselect default_variants if they are conflicting, like in the python24/python25 case... But after all, it makes sense to write something like -python25 +python24 (think that as "without python25, with python24").
Many might do "-gnome" and miss python or "python24" and miss gnome ... That is the problem with default variants.
Default variants are implemented as they have to be explicitely deselected if someone does not want them. But deselecting one variant does still select others from default_variants. I find a good example is the herrie port. It has some default_variants set, but you can deselect them and/or select additional variants. Some examples: port install herrie installs herrie 1.8.1_0+http+mp3+scrobbler+vorbis+xspf port install herrie -http installs herrie 1.8.1_0+mp3+scrobbler+vorbis+xspf port install herrie -http +modplug installs herrie 1.8.1_0+modplug+mp3+scrobbler+vorbis+xspf Hope it is now more clear how that works and what I meant. Rainer
On Aug 4, 2007, at 04:03, Rainer Müller wrote:
The point is that internals and default become less transparant and more complex for the user.
I admit it is a little bit more complex to deselect default_variants if they are conflicting, like in the python24/python25 case... But after all, it makes sense to write something like -python25 +python24 (think that as "without python25, with python24").
See my ports minivmac and pdftk for workarounds to make this easier for the user. I only select the default_variants if no conflicting variants have been selected. minivmac can emulate several early Mac models. If you don't specify otherwise, it emulates a Mac Plus. if { ![variant_isset mac128k] && ![variant_isset mac512k] && ! [variant_isset mac512ke] && ![variant_isset macse] } { default_variants +macplus } variant mac128k conflicts mac512k mac512ke macplus macse description {Emulate a Macintosh with 128K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac128k.diff } variant mac512k conflicts mac128k mac512ke macplus macse description {Emulate a Macintosh 512K with 512K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac512k.diff } variant mac512ke conflicts mac128k mac512k macplus macse description {Emulate a Macintosh 512Ke with 512K RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-mac512ke.diff } variant macplus conflicts mac128k mac512k mac512ke macse description {Emulate a Macintosh Plus with 4 MB RAM and 6 drives (default)} { # Mac Plus emulation is the default so we don't need to do anything here } variant macse conflicts mac128k mac512k mac512ke macplus description {Emulate a Macintosh SE with 4 MB RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-macse.diff } pdftk can be compiled with any version of gcc. By default I want to use the latest, gcc42, but if the user is on a slow PowerPC Mac and already has an earlier gcc and doesn't want to spend a day upgrading, they can use another variant. if { ![variant_isset with_gcc34] && ![variant_isset with_gcj34] && ! [variant_isset with_gcc41] && ![variant_isset with_gcc42] } { default_variants +with_gcc42 } variant with_gcc34 conflicts with_gcj34 with_gcc41 with_gcc42 i386 description {Build using gcc34 (PowerPC only)} { depends_lib-append port:gcc34 build.args-append VERSUFF=-dp-3.4 } variant with_gcj34 conflicts with_gcc34 with_gcc41 with_gcc42 i386 description {Build using gcj34 (PowerPC only)} { depends_lib-append port:gcj34 build.args-append TOOLPATH=${prefix}/gcj34-3.4.5/bin/ } variant with_gcc41 conflicts with_gcc34 with_gcj34 with_gcc42 i386 description {Build using gcc41 (PowerPC only)} { depends_lib-append port:gcc41 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.1 } variant with_gcc42 conflicts with_gcc34 with_gcj34 with_gcc41 description {Build using gcc42 (default)} { depends_lib-append port:gcc42 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.2 } platform i386 {}
Le 07-08-04 à 06:53, Ryan Schmidt a écrit :
On Aug 4, 2007, at 04:03, Rainer Müller wrote:
The point is that internals and default become less transparant and more complex for the user.
I admit it is a little bit more complex to deselect default_variants if they are conflicting, like in the python24/python25 case... But after all, it makes sense to write something like -python25 +python24 (think that as "without python25, with python24").
See my ports minivmac and pdftk for workarounds to make this easier for the user. I only select the default_variants if no conflicting variants have been selected.
minivmac can emulate several early Mac models. If you don't specify otherwise, it emulates a Mac Plus.
if { ![variant_isset mac128k] && ![variant_isset mac512k] && ! [variant_isset mac512ke] && ![variant_isset macse] } { default_variants +macplus }
variant mac128k conflicts mac512k mac512ke macplus macse description {Emulate a Macintosh with 128K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac128k.diff }
variant mac512k conflicts mac128k mac512ke macplus macse description {Emulate a Macintosh 512K with 512K RAM and 2 drives} { patchfiles-append patch-CNFGGLOB.h-mac512k.diff }
variant mac512ke conflicts mac128k mac512k macplus macse description {Emulate a Macintosh 512Ke with 512K RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-mac512ke.diff }
variant macplus conflicts mac128k mac512k mac512ke macse description {Emulate a Macintosh Plus with 4 MB RAM and 6 drives (default)} { # Mac Plus emulation is the default so we don't need to do anything here }
variant macse conflicts mac128k mac512k mac512ke macplus description {Emulate a Macintosh SE with 4 MB RAM and 6 drives} { patchfiles-append patch-CNFGGLOB.h-macse.diff }
pdftk can be compiled with any version of gcc. By default I want to use the latest, gcc42, but if the user is on a slow PowerPC Mac and already has an earlier gcc and doesn't want to spend a day upgrading, they can use another variant.
if { ![variant_isset with_gcc34] && ![variant_isset with_gcj34] && ! [variant_isset with_gcc41] && ![variant_isset with_gcc42] } { default_variants +with_gcc42 }
variant with_gcc34 conflicts with_gcj34 with_gcc41 with_gcc42 i386 description {Build using gcc34 (PowerPC only)} { depends_lib-append port:gcc34 build.args-append VERSUFF=-dp-3.4 }
variant with_gcj34 conflicts with_gcc34 with_gcc41 with_gcc42 i386 description {Build using gcj34 (PowerPC only)} { depends_lib-append port:gcj34 build.args-append TOOLPATH=${prefix}/gcj34-3.4.5/bin/ }
variant with_gcc41 conflicts with_gcc34 with_gcj34 with_gcc42 i386 description {Build using gcc41 (PowerPC only)} { depends_lib-append port:gcc41 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.1 }
variant with_gcc42 conflicts with_gcc34 with_gcj34 with_gcc41 description {Build using gcc42 (default)} { depends_lib-append port:gcc42 build.args-append TOOLPATH=${prefix}/bin/ VERSUFF=-mp-4.2 }
platform i386 {}
This is exactly my point. Everything gets complex and confusing. I understand the use of default variants in the 2 cases above because you have many excluding options. But it's just not the best solution when adding or leaving an option. Maybe "+wihout" is not nice in a logical point of view, but it's simple and straightforward. yves
participants (5)
-
Daniel J. Luke
-
Rainer Müller
-
Ryan Schmidt
-
Xin Liu
-
Yves de Champlain