Date: Wed, 02 Jul 2014 10:11:19 +1000 From: Kubilay Kocak <koobs@FreeBSD.org> To: CeDeROM <cederom@tlen.pl> Cc: freebsd-hackers@freebsd.org, freebsd-ports <freebsd-ports@freebsd.org> Subject: Re: port - python dependencies and github master Message-ID: <53B34E27.7090808@FreeBSD.org> In-Reply-To: <CAFYkXjnTx0pOEzB-bjNtSv=bbgxsP6C6mTeOTicayz8JWJY4iQ@mail.gmail.com> References: <CAFYkXjkb2UsKHb3=uFz4yZBHG7GDK7QrnJA2dfm4_jn_S5coZg@mail.gmail.com> <53B33B12.8030005@FreeBSD.org> <CAFYkXjnTx0pOEzB-bjNtSv=bbgxsP6C6mTeOTicayz8JWJY4iQ@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/07/2014 9:44 AM, CeDeROM wrote:
> Hello Koobs and thank you for your hints!! :-)
>
> On Wed, Jul 2, 2014 at 12:49 AM, Kubilay Kocak <koobs@freebsd.org> wrote:
>>> 1. How to change PORTVERSION / GH_COMMIT based on user choice /
>>> option? One value for PORTVERSION seems fine but to change it to
>>> master does not work..
>>
>> You very probably don't want to do this. PORTVERSION needs to be static,
>> in the sense that it can't be conditional.
>
> Ugh, thats the problem. I have notcied that :-( At least for the first
> time I change the Makefile both RELEASE and DEVEL works, but then it
> does not work... just as Makefile was somehow cached and remembers
> PORTVERSION even if I change its value it still use the old value or
> any numeric value which is found on the Makefile even inside
> conditional statement.. strange :-)
>
>
>> This is because PORTVERSION plus a few other variables is how the ports
>> framework derives DISTFILES, who's checksums must remain consistent
>> unless changed/updated by the maintainer (see distinfo file)
>
> I would like to make a port to build a package by default, but also I
> would like to have option to build a devel package. No additional port
> for that is necessary. That would save frequent port updates, just one
> smart Makefile that would do the job :-) This seems sensible, but I
> have noticed checksum problems here when PORTVERSION is changed on the
> fly..
The first question is do you want these ports in the ports tree, or just
to keep locally?
If you want them in the tree, then a separate py-foo and py-foo-devel is
recommended.
If not, you may be able to get away with a single port that can build
both. That's a more involved discussion that is best done on IRC in
real-time, and you'll benefit from more people to talk to who might have
different suggestions to achieve what you want
> Other question if additional cura-devel port is mandatory - how can I
> fetch HEAD and then get the commit number to add to the package name
> to distinguish different builds? If PORTVERSION must be static, then
> should I add some package suffix that can be based on a dynamic
> value/variable?
Unfortunately master/head/tip are moving targets and the commit hash
changes over time.
You can however, pin to a particular commit using the hash as the tag:
GH_TAGNAME=${GH_COMMIT}
GH_COMMIT=<hash>
>
>>> 2. Is the way to check python modules dependency correct?
>>>
>>> PORTNAME= cura
>>> PORTVERSION= 14.06
>>> #STABLEREL= 14.06
>>> CATEGORIES= cad
>>
>> Add the 'python' category as a secondary category to Python ports
>
> ACK! :-)
>
>
>>> MAINTAINER= blah@blah
>>> COMMENT= Cura is a complete and open slicing solution for
>>> RepRap 3D printers.
>>
>> Don't include the package/software name or indefinite articles (A/An) in
>> COMMENT. Also strip the trailing full stop (period).
>
> ACK! :-)
>
>
>>> OPTIONS_SINGLE= BTYPE
>>> OPTIONS_SINGLE_BTYPE= RELEASE DEVEL
>>> OPTIONS_SUB= yes
>>> RELEASE_DESC= Build latest stable release from github (${PORTVERSION})
>>> DEVEL_DESC= Build latest development snapshot from github master
>>> OPTIONS_DEFAULT= RELEASE
>>>
>>> .include <bsd.port.options.mk>
>>>
>>> #.if ${PORT_OPTIONS:MRELEASE}
>>> #PORTVERSION= ${STABLEREL}
>>> #.endif
>>>
>>> .if ${PORT_OPTIONS:MDEVEL}
>>> PORTVERSION= master
>>> #STABLEREL= master
>>> .endif
>>>
>>> #PORTVERSION= ${STABLEREL}
>>>
>>> USE_PYTHON= yes
>>
>> You at least want USE_PYDISTUTILS=yes here, and maybe
>> PYDISTUTILS_AUTOPLIST=yes also.
>>
>> See /usr/ports/Mk/bsd.python.mk for more information.
>
> ACK! :-)
>
>
>>> RUN_DEPENDS+=
>>
>> First assignment of {RUN,BUILD}_DEPENDS should be = not +=
>>
>>> ${PYTHONPREFIX_SITELIBDIR}/OpenGL:${PORTSDIR}/graphics/py-opengl \
>>> ${PYTHONPREFIX_SITELIBDIR}/numpy:${PORTSDIR}/math/py-numpy \
>>>
>>> ${PYTHONPREFIX_SITELIBDIR}/setuptools:${PORTSDIR}/devel/py-setuptools
>>> \
>>> ${PYTHONPREFIX_SITELIBDIR}/serial:${PORTSDIR}/comms/py-serial
>>> BUILD_DEPENDS+= git:${PORTSDIR}/devel/git
>>
>> If you're not depending on a binary (like the git line above), the
>> simplest way is to depend on the package names. Eg:
>>
>> ${PYTHON_PKGNAMEPREFIX}setuptools>[0|<version>]:${PORTSDIR}/category/<portname>
>
> I know the Porter's Handbook, but there is no information on how to
> verify the dependencies on python modules. Using
> ${PYTHON_PKGNAMEPREFIX} would search for binaries, which is not the
> case. This is why I have "invented" ${PYTHONPREFIX_SITELIBDIR}/OpenGL
> which works well and checks if a given python module is available :-)
You 'can' check for the existence of files in sitelibdir or
site-packages, but you want to consider how robust it is compared to
depending on the package instead (${PYTHON_PKGNAMEPREFIX}<foo>)
With this option, you have the option to use version checks such as >,
>=, ==, etc, which you can't with files. This is beneficial in most
scenarios.
Rule of thumb: Use any of file, dir, executable or package, default to
package name, and use the others if and when there is a good reason to.
>
>> If you need any porting help, we have a few IRC channels available for you:
>>
>> 1) #freebsd-ports - freenode
>> 2) #freebsd-python - freenode
>> 3) #bsdports - Efnet
>
> Thank you I will connect that way! :-)
>
> Best regards :-)
> Tomek
>
You're welcome!
--
koobs
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?53B34E27.7090808>