Kevin Van Vechten | kevin@opendarwin.org 9-Oct-2002
Beaucoup de logiciels ont des fonctionnalités optionnelles qui ont besoin d'être définies au moment de la compilation. Ces logiciels sont soit compilés avec ou sans le support de certaines fonctions. Un des exemples les plus flagrant est de compiler un logiciel avec ou sans le support d'X11.
Les variantes furent créer pour pallier à ce besoin d'avoir ou non ces fonctionnalités supplémentaires. Souvent, compiler avec ou sans le support d'X11 est juste l'affaire de spécifier --with-x11 ou --without-11 dans la variable configure.args. En gros, une variante est l'équivalent de la déclaration if en Tcl. Donc si la variante a été spécifiée par l'utilisateur, le bloc de code est exécuté. Voici un exemple d'une variante pour X11 :
configure.args --without-x11
variant x11 {
configure.args-delete --without-x11
configure.args-append --with-x11
}
Normalement, le code se situant en dehors du bloc dédié à la variante est exécuté sans réserve avant que toute variante soit prise en compte. Cepdendant, si +x11 a été spécifiée, les déclarations configure.args-delete et configure.args-append seront également prises en compte.
Si deux variantes sont définies, par exemple x11 et kde, une des deux ou carrément les deux peuvent être choisies et utilisées par l'utilisateur. Spécifier +x11 aura pour effet de prendre en compte la variante x11, et spécifier +kde aura pour effet la prise en compte de la variante kde. Si +x11 +kde est spécifiée, les deux variantes seront prises en compte. Il est également possible de définir des variantes contenant plusieurs termes. Par exemple :
variant x11 kde {
# do something here, when both x11 and kde are selected
}
Dans cet exemple, la variante x11-kde sera exécutée uniquement si x11 et +kde sont spécifiées. Cela permet aux conflits entre deux variantes "primitives" d'être résolues sans beaucoup d'efforts. Aussi, parce que ces variantes combinées sont le plus souvent utilisées pour résoudre des conflits, elles sont prises en compte après que chaque parties constituantes aient été prises en compte.
Parfois il est utile de garantir qu'une variante soit lancée après une autre variante. Cela peut rendre la manipulation des variables plus franche, plus souple, valable également pour d'autres opérations. L'agencement peut se faire grâce au mot-clé follows. (Important : le mot-clé follows n'a pas encore été implémenté.) Dans l'exemple suivant, la variante kde déclare que même si +kde et +x11 sont spécifiées, la variante kde sera toujours prise en compte après la variante x11. La variante kde restera prise en compte même si seulement +kde est spécifiée.
variant kde follows x11 {
# do something here, after x11
}
D'un autre côté, il est possible d'autoriser kde a être une variante si et uniquement si x11 a également été sélectionnée. Cela peut être fait en utilisant le mot-clé requires, utilisé de la manière suivante :
variant kde requires x11 {
# do something here, only after x11
}
Un Portfile peut contenir un set par défaut de variantes, qui sera sélectionné lors de la prise en charge du Portfile, à moins que l'utilisateur ne les ait explicitement refusés. Cela peut être fait en utilisant la commande default_variants dans le Portfile, comme ci-dessous :
default_variants +x11 +kde
Cela indique que les variantes x11 et kde seront prises en compte à moins que l'utilisateur n'ait spécifié -kde -x11 à la ligne de commande.
Quelques variantes sont implicitement spécifiées par le système. Comme les variantes par défaut, celles-ci peuvent être annulées à la ligne de commande. Actuellement la plateforme et l'architecture sont deux variantes implicites. Les variantes du même nom que les valeurs de os.platform et os.arch sont sélectionnées. os.platform contient la valeur d'uname -s comme darwin ou freebsd. os.arch contient la valeur d'uname -p comme ppc ou i386.