Variants handling: my $0.02.
N_Ox
nox at macports.org
Mon Feb 4 08:34:13 PST 2008
Hello there,
One thing that is great about MacPorts is to be able to customise
ports with variants.
But there is two problems with them, I've thought about 2 new
syntaxes to handle these problems.
First, when a variant actually does something only when it is
DISABLED, you would usually need to write:
variant some_variant {}
post-patch {
if {![variant_isset some_variant]} {
# Do something
}
}
Why wouldn't we just write:
variant -some_variant {
post-patch {
# Do something
}
}
Now, what if we want to do something when the variant is enabled, and
something else when it is disabled?
Why won't we write that:
variant some_variant {
# Do something
} else {
# something else
}
Isn't that neat?
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".
Then, on upgrade, we would just have to compare the name of the
variant in the portfile (-some_variant) with each item of the list of
selected variants to check whether or not we should enable it.
No need to use default_variants.
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
}
But maybe all of this is just a "No more alive nerve cells in my brain."
Regards,
--
Anthony Ramine, the "Ports tree cleaning Maestro".
<nox at macports.org>
More information about the macports-dev
mailing list