Variants handling: my $0.02.
N_Ox
nox at macports.org
Mon Feb 4 11:23:45 PST 2008
Le 4 févr. 08 à 18:13, Rainer Müller a écrit :
> N_Ox wrote:
>> These two sugar syntaxes would make the variant writing process
>> cleaner.
>> But maybe they could help us more...
>> Let's say the variants which do something only when they are
>> disabled (variant -some_variant) are always enabled by default.
>> In this setup, `sudo port install some_port +another_variant`
>> would install some_port @some_version+another_variant+some_variant.
>> In the registry, we would save "some_variant another_variant" as
>> the list of selected variants.
>> Now, let's explicitely disable the variant: sudo port install
>> some_port -some_variant +another_variant.
>> In the registry, we would save "-some_variant another_variant".
>
> Should the selection of -some_variant be user visible or just
> stored internal?
> port installed some_port
> 1) some_port at 1.0+another_variant-some_variant
> 2) some_port at 1.0+another_variant
Shown to the user
> The main problem about default_variants in it's current
> implementation is that we don't store disabled variants and re-
> select them on upgrade...
AFAIK, default_variants is just a procedure that append any argument
to the list of enabled variants in the registry.
This syntax remove the need to use default_variants.
>> No need to use default_variants.
>
> So how would I tell that a +variant is default? E.g. the lynx port
> provides support for OpenSSL (+ssl) and GNU TLS (+gnutls). They are
> conflicting variants, with +ssl in default_variants. But the user
> has the choice to install it with GNU TLS by using -ssl +gnutls.
>
> But how would I write that in the new syntax?
>
>> No more "Why the hell this variant is enabled when I upgrade this
>> port?" whining.
>> No more "no_x11" variant:
>> variant -x11 {
>> # no x11
>> } else {
>> # x11
>> }
>
> And which of those will be the default...? You said -some_variant
> will be enabled by default, or did I understand that wrong? In
> which cases will -some_variant be enabled by defaul? If it got no
> else-block?
> I think that will end up more complex than it currently is...
Not complex, at least that's not what I think.
The algorithm would be:
foreach {name} ${variants} {
# Foreach variant defined in the portfile
if {[lindex ${selected_variants} ${name}] > -1} {
# If this variant is selected.
eval_variant ${name} # The first block.
} elseif {[variant_has_else_block ${name}]} {
eval_else_variant ${name} # The else block
}
}
If a -variant hasn't been SELECTED (through the command line), it is
ENABLED, it did NOT show up in `port installed` and the else block
will be evaluated.
If a (+)variant hasn't been SELECTED (through the command line), it
is DISABLED, it did NOT show up in `port installed` and the else
block will be evaluated.
So the behaviour is in fact the very same for both of them.
> Also, what is the difference between these and which one is a
> default variant?
>
> variant foo {
> # do something
> }
A normal variant:
port install -> @... (nothing evaluated)
port install +foo -> @...+foo (first block evaluated)
port install -foo -> @... (nothing evaluated)
> variant -bar {
> # do something
> } else {
> # do something
> }
A negative variant which does something else when it's not enabled:
port install -> @... (else block evaluated)
port install +bar -> @... (else block evaluated)
port install -bar -> @...-bar (first block evaluated)
> variant -baz {
> # do something
> }
A negative variant:
port install -> @... (nothing evaluated)
port install +baz -> @... (nothing evaluated)
port install -baz -> @...-baz (first block evaluated)
> What if we add some new flag? I like the idea of variant -
> some_variant, but maybe we could also add a default keyword which
> says if this variant is going to be installed by default.
>
> Like this:
> variant x11 description {Install X11 support} default {
> # x11
> } else {
> # no x11
> }
Sure. The -variant syntax just sounds more intuitive to me, but one
could say I'm strange.
> I like the overall idea to simplify the default variants handling!
>
> Rainer
--
Anthony Ramine, the "Ports tree cleaning Maestro".
<nox at macports.org>
More information about the macports-dev
mailing list