Update libdnet to 1.10. Add python support. That was less easy than it might have been. Logic of if's: python is installed (1), WITH_PYTHON selected: no banner, add support. python is installed, WITH_PYTHON not selected: no banner, add support. python not installed, WITH_PYTHON selected: no banner, install python(2), add support. python not installed, WITH_PYTHON not selected: show banner, no support. Note the hack of inclusion of bsd.python.mk. This is done to generalize PYTHON_VERSION. If you can suggest a better alternative, I'm willing to learn. This file would be more readable if there was a version of PYTHON_SITELIBDIR without LOCALBASE, for inclusion into PLIST_FILES. But there isn't. I realize now I could have made my life much easier if I only cared about WITH_PYTHON and not about if it's actually installed. Oh well... Is there any point in using OPTIONS if there's only one option? 1 - ${LOCALBASE}/bin/python exists. 2 - should be done because of BUILD_DEPENDS. untested. Fix: http://www.sl0th.org/FreeBSD/libdnet-1.9-1.10.diff How-To-Repeat: N/A
> I realize now I could have made my life much easier if I only cared > about WITH_PYTHON and not about if it's actually installed. Oh well... So why you did not go this way? -- Sem.
On Mon, 14 Mar 2005 16:57:10 +0300, Sergey Matveychuk <sem@freebsd.org> wrote: > > I realize now I could have made my life much easier if I only cared > > about WITH_PYTHON and not about if it's actually installed. Oh well... > > So why you did not go this way? Because I wanted the default install to be sensible. That is, if you have installed python already, you'll get python support. If you didn't install python, you won't get python support unless you ask for it, because asking for it means installing python.
This kind of smartness is not a good idea in general, because it does not translate to binary packages. It's especially unsuitable for language-bindings - if at some point another port needs libdnet's python-bindings, it will have no way of depending on them. Consider creating a slave-port for the python-bindings instead. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
On Mon, 14 Mar 2005 15:41:08 +0100, Michael Nottebrock <michaelnottebrock@gmx.net> wrote: > This kind of smartness is not a good idea in general, because it does not > translate to binary packages. It's especially unsuitable for > language-bindings - if at some point another port needs libdnet's > python-bindings, it will have no way of depending on them. Consider creating > a slave-port for the python-bindings instead. Are you sure? IMO it seems hardly justified, because it will create too many flavour-ports. Will changing it to rely only on WITH_PYTHON (or WITHOUT_.., I don't care) be enough? If you feel strongly about it, though, then I have no problem with splitting this port.
I have no feelings or immediate interest in this port at all (for now), I'm just pointing out possible scenarios. There might be no users of libdnet's python-bindings right now in ports, and perhaps there never will be - but since language-bindings are usually made to be used, there's a pretty good chance that one day somebody will make a port that will need to depend on them - and then you'll either have to create that slave-port after all or change WITH_PYTHON to default to on. -- ,_, | Michael Nottebrock | lofi@freebsd.org (/^ ^\) | FreeBSD - The Power to Serve | http://www.freebsd.org \u/ | K Desktop Environment on FreeBSD | http://freebsd.kde.org
Jonatan B wrote: > Are you sure? IMO it seems hardly justified, because it will create > too many flavour-ports. Will changing it to rely only on WITH_PYTHON > (or WITHOUT_.., I don't care) be enough? > If you feel strongly about it, though, then I have no problem with > splitting this port. Yep. I like the idea much more too. -- Sem.
So what's the resolution on this one? -- Pav Lucistnik <pav@oook.cz> <pav@FreeBSD.org> It's time for the penguin on top of your television set to explode.
State Changed From-To: open->closed Committed, thanks! I just removed autodetection of python from the checks, the knob is there and defaults to off.