Changeset View
Standalone View
Mk/Uses/django.mk
- This file was added.
Property | Old Value | New Value |
---|---|---|
svn:eol-style | null | native \ No newline at end of property |
svn:keywords | null | FreeBSD=%H \ No newline at end of property |
svn:mime-type | null | text/plain \ No newline at end of property |
# $FreeBSD$ | |||||
# | |||||
# Provide django support | |||||
# | |||||
# Usage: USES=django[:version] | |||||
# | |||||
# MAINTAINER: python@FreeBSD.org | |||||
.if !defined(_INCLUDE_USES_DJANGO_MK) | |||||
_INCLUDE_USES_DJANGO_MK= yes | |||||
# Please keep in sync with the comment in Mk/bsd.default-versions.mk | |||||
mat: I do not think adding python to post is needed, all ports should be using USES=python too. | |||||
Done Inline ActionsAh -- OK. That's me not understanding what _USES_POST actually does. I thought it was all about controlling the order that Uses are processed in. matthew: Ah -- OK. That's me not understanding what _USES_POST actually does. I thought it was all… | |||||
Done Inline ActionsThe Uses are processed in the order they are given. Uses are invoked a first time during bsd.port.pre.mk, and _USES_POST is used to say that this USES has a "post" section that will be invoked later, in bsd.port.post.mk. mat: The Uses are processed in the order they are given.
Uses are invoked a first time during bsd. | |||||
_DJANGO_VALID_VERSIONS= 1.11 1.10 1.8 | |||||
Done Inline Actionspy-django20 has landed in ports so 2.0 can be added here. FreeBSD_ShaneWare.Biz: py-django20 has landed in ports so 2.0 can be added here.
| |||||
.if ! ${_DJANGO_VALID_VERSIONS:M${DJANGO_DEFAULT}} | |||||
IGNORE= Invalid django version ${DJANGO_DEFAULT} | |||||
.endif | |||||
# | |||||
# Parse a version+ argument | |||||
# | |||||
.if ${django_ARGS:M*+} | |||||
_DJANGO_MIN_VERSION:= ${django_ARGS:S/+//} | |||||
.endif | |||||
# | |||||
# Parse one or more version arguments. We're verifying that | |||||
# _DJANGO_DEFAULT_VERSION is one of the versions suitable for the port | |||||
# -- failing that, we have to set IGNORE | |||||
# | |||||
.for _v in ${_DJANGO_VALID_VERSIONS} | |||||
. if ${django_ARGS:M${_v}} | |||||
_DJANGO_CANDIDATE_VERSIONS+= ${_v} | |||||
. endif | |||||
.endfor | |||||
# | |||||
# Resolve minimum versions (version+). Append anything equal or | |||||
# greater than the specified minimum version to the list of wanted | |||||
# versions. | |||||
# | |||||
.if defined(_DJANGO_MIN_VERSION) | |||||
. for _v in ${_DJANGO_VALID_VERSIONS} | |||||
. if ( ${_DJANGO_MIN_VERSION:R} <= ${_v:R} ) && ( ${_DJANGO_MIN_VERSION:E} <= ${_v:E} ) | |||||
_DJANGO_CANDIDATE_VERSIONS+= ${_v} | |||||
. endif | |||||
. endfor | |||||
.endif | |||||
# | |||||
# If no version was specified with either version or version+ | |||||
# arguments, set the default version. | |||||
# | |||||
.if !defined(_DJANGO_CANDIDATE_VERSIONS) | |||||
_DJANGO_WANTED_VERSION:= ${DJANGO_DEFAULT} | |||||
.else | |||||
# | |||||
# Right now we have built a list of potential versions that we may | |||||
# depend on. Let's sort them and remove any duplicates. | |||||
# | |||||
# If the selected default version is one of the wanted versions, use | |||||
# that. | |||||
# | |||||
. for _v in ${_DJANGO_CANDIDATE_VERSIONS:O:u} | |||||
. if ${DJANGO_DEFAULT} == ${_v} | |||||
_DJANGO_WANTED_VERSION:= ${_v} | |||||
. endif | |||||
. endfor | |||||
.endif | |||||
# | |||||
# Otherwise we have a port that needs a version of Django other than | |||||
# the specified default, so we should set IGNORE. | |||||
# | |||||
Done Inline ActionsThis is a bug, if it can't find a wanted version, it should prefer the default version instead of the highest one antoine: This is a bug, if it can't find a wanted version, it should prefer the default version… | |||||
Done Inline ActionsYes, this is wrong, but not in the way you state. This is trying to handle the situation where eg. DEFAULT_VERSIONS contains django=1.8 but the port says something like USES=django:110+ In this case I should probably just set IGNORE matthew: Yes, this is wrong, but not in the way you state. This is trying to handle the situation where… | |||||
Done Inline ActionsIf you USES=django:18+ it will choose the highest version too instead of using the default one antoine: If you USES=django:18+ it will choose the highest version too instead of using the default one | |||||
Done Inline ActionsNow it will choose ither the default version, or the port will be ignored. matthew: Now it will choose ither the default version, or the port will be ignored. | |||||
.if !defined(_DJANGO_WANTED_VERSION) | |||||
IGNORE= Port requires django version ${django_ARGS} which cannot be satisfied by the default version ${DJANGO_DEFAULT} | |||||
.endif | |||||
# | |||||
# Exported variables | |||||
# | |||||
DJANGO_VER_STR= ${_DJANGO_WANTED_VERSION:S/.//g} | |||||
DJANGO_VER= ${_DJANGO_WANTED_VERSION} | |||||
DJANGO_PKGNAMEPREFIX= ${PYTHON_PKGNAMEPREFIX}django${DJANGO_VER}- | |||||
Done Inline ActionsRemoving '.' leads to DJANGO_VER being 111,110,18,20 - meaning 2.0 will compare as less than 1.10. Could DJANGO_VER be made as three digit? (108,110,111,200) Maybe add DJANGO_REL as three digit similar to PYTHON_REL. FreeBSD_ShaneWare.Biz: Removing '.' leads to DJANGO_VER being 111,110,18,20 - meaning 2.0 will compare as less than 1. | |||||
RUN_DEPENDS+= ${PYTHON_PKGNAMEPREFIX}django${DJANGO_VER_STR}>=0:www/py-django${DJANGO_VER_STR} | |||||
.endif | |||||
Not Done Inline ActionsI do not see this FLAVORS variable defined beforehand, where does it come from exactly ? mat: I do not see this FLAVORS variable defined beforehand, where does it come from exactly ? | |||||
Not Done Inline ActionsThat's what is set in python.mk matthew: That's what is set in python.mk
| |||||
Not Done Inline ActionsMmm, but django < python, you can absolutely assume that the sort police will put django before python and it will break. You need to add a .include "${USESDIR}/python.mk" before you use any variables coming from python.mk. mat: Mmm, but django < python, you can absolutely assume that the sort police will put django before… | |||||
Not Done Inline ActionsAgreed that there will be some people who sort the USES line, but not for long. That's why I put in the check for .if !defined(_INCLUDE_USES_PYTHON_MK) at line 70 -- all they'll get is an error message which, I trust, will help to educate them that sorting things is not always a good idea. Notice that the body of this file is in the .else branch of that test, so none of the python variables will be processed unless python.mk has already been included. If I include ${USESDIR}/python.mk doesn't that break processing any arguments for the python USES? matthew: Agreed that there will be some people who sort the USES line, but not for long. That's why I… | |||||
Not Done Inline ActionsUSES must work the same way whatever their order is. USES are self contained, and many include other because of dependencies. It should not break anything. mat: USES must work the same way whatever their order is.
USES are self contained, and many include… | |||||
Not Done Inline ActionsThat's a problem when you've got several different USES each trying to define FLAVOR and FLAVORS -- it's presumably the last-added USES that wins, which breaks the requirement about invariance to ordering. I'm thinking we need a rule that any variables that a USES .mk file defines should have a distinct namespace eg. PY_FLAVOR, PY_FLAVORS; DJANGO_FLAVOR, DJANGO_FLAVORS. For flavour handling specifically, the USES could append their namespace prefix to a generic variable, say FLAVOR_NAMESPACES+=PY and then a separate block of code in bsd.ports.mk to combine the flavors from the different namespaces (sorted alphabetically), with a mechanism to filter out incompatible combinations (eg. py27 doesn't mix with django20). Individual ports could override this mechanism by setting the un-namespaced variables FLAVOR or FLAVORS as now. matthew: That's a problem when you've got several different USES each trying to define FLAVOR and… |
I do not think adding python to post is needed, all ports should be using USES=python too.