Changeset View
Standalone View
devel/py-clint/Makefile
# Created by: Nicola Vitale <nivit@FreeBSD.org> | # Created by: Nicola Vitale <nivit@FreeBSD.org> | ||||
# $FreeBSD$ | # $FreeBSD$ | ||||
PORTNAME= clint | PORTNAME= clint | ||||
PORTVERSION= 0.5.1 | PORTVERSION= 0.5.1 | ||||
#PORTREVISION= 0 | #PORTREVISION= 0 | ||||
CATEGORIES= devel | CATEGORIES= devel | ||||
MASTER_SITES= CHEESESHOP | MASTER_SITES= CHEESESHOP | ||||
PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} | PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX} | ||||
MAINTAINER= nivit@FreeBSD.org | MAINTAINER= nivit@FreeBSD.org | ||||
COMMENT= Python command-line application tools | COMMENT= Python command-line application tools | ||||
LICENSE= ISCL | LICENSE= ISCL | ||||
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}args>=0.1.0:devel/py-args | FLAVORS= python2 python3 | ||||
RUN_DEPENDS= ${PYTHON_PKGNAMEPREFIX}args>=0.1.0:devel/py-args@${FLAVOR} | |||||
franco_opnsense.org: Is this required for the sub-build? would it not be better to pass it through the framework… | |||||
Not Done Inline ActionsThe pass through is impossible, my example here is pretty bad because it gives an example where the flavor the port depends on is actually the same as the flavors of this port, but that is not always the case bapt: The pass through is impossible, my example here is pretty bad because it gives an example where… | |||||
Not Done Inline ActionsI see, this is for selecting a particular flavour of the dependency, not adding a dependency for the port itself. got it. franco_opnsense.org: I see, this is for selecting a particular flavour of the dependency, not adding a dependency… | |||||
Not Done Inline ActionsThis FLAVOR= thing is not needed in *this case*. This is what DEPENDS_ARGS is used for and the python framework already does this. .if !defined(PYTHON_NO_DEPENDS) DEPENDS_ARGS+= PYTHON_VERSION=${PYTHON_VERSION} .endif So when you build py-lint with make arg FLAVOR=python3, it will pass DEPENDS_ARGS=PYTHON_VERSION=python3 down to all dependencies. I have a basic PoC patch for Poudriere to handle FLAVORS already that did not need this FLAVOR argument. Note I said "*this case*". It is certainly possible and useful to depend on a specific FLAVOR for a package. But in this case it is superfluous. Also note that this last argument here passing FLAVOR=foo down to a dependency *will also still* pass DEPENDS_ARGS values and may cause odd conflict and confusion, which is why I suggest we don't use it in this FLAVOR=${FLAVOR} method, rather than more explicit FLAVOR=explicit_flavor. bdrewery: This `FLAVOR=` thing is not needed in *this case*. This is what `DEPENDS_ARGS` is used for and… | |||||
USES= python | USES= python | ||||
Not Done Inline ActionsActually, this does not need python framework support at all then... or am i missing something? USES?= python franco_opnsense.org: Actually, this does not need python framework support at all then... or am i missing something? | |||||
Not Done Inline Actionsno the way it has been hooked to python.mk it will work out of box without the requirement of python2_USES In any case we can't reuse the mechanism of options helpers as we might end with collisions bapt: no the way it has been hooked to python.mk it will work out of box without the requirement of… | |||||
Not Done Inline Actionsunderstood. still a bit of a bummer, because the use of flavours would be very much flexible with this :) in any case, great work and thanks for the explanations franco_opnsense.org: understood. still a bit of a bummer, because the use of flavours would be very much flexible… | |||||
Not Done Inline ActionsThis is a basic first implementation, flexibility will come later along with the complex use cases :) bapt: This is a basic first implementation, flexibility will come later along with the complex use… | |||||
Not Done Inline ActionsFlavors are only shown being used very simply here. If you have a port that has, say, a GNOME and a KDE option, you can do stuff like: FLAVORS= gnome kde .if defined(FLAVOR) && ${FLAVOR:Mgnome} OPTIONS_SLAVE+= GNOME OPTIONS_EXCLUDE+= KDE .endif .if defined(FLAVOR) && ${FLAVOR:Mkde} OPTIONS_SLAVE+= GNOME OPTIONS_EXCLUDE+= KDE .endif Which is a bit awful, so we may end up adding options helpers to set options depending on the flavor being used. mat: Flavors are only shown being used very simply here. If you have a port that has, say, a GNOME… | |||||
USE_PYTHON= autoplist distutils | USE_PYTHON= autoplist distutils | ||||
.include <bsd.port.mk> | .include <bsd.port.mk> |
Is this required for the sub-build? would it not be better to pass it through the framework rather than explicitly here?
Also, is something like this thinkable in the future to do a "top down flavour" without adding framework support?
python2_RUN_DEPENDS= etc.