On Thu, Dec 06, 2001 at 12:33:58AM -0500, James Chacon wrote:
> 
> Then I see other python things like extension.buildlink.mk in the python
> directory and a package using that.
> 
> Then some more use Makefile.inc from the python dir..
> 
> So, which method should one be using? It looks like the buildlink method
> I'm guessing. 

extension.buildlink.mk doesn't actually have any relationship with the
other buildlink stuff in pkgsrc, other than that you include the file in
the package Makefile.  It's misnamed.  I believe that the code in
extension.buildlink.mk is the way to go, though, as it replaces much of
the contents of python.mk.

> In both the buildlink and python-mk stuff they both check:
> 
> .if ${MACHINE_ARCH} == "powerpc" || ${MACHINE_ARCH} == "mips" || ${MACHINE_ARCH} == "vax"
> IGNORE="${PKGNAME} needs dynamic loading"
> .endif
> 
> Why does powerpc claim it can't do dynamic loading? As far as I know the
> powerpc has no problems with dlopen calls.

The python.mk stuff was written first, and may have been from the days when
powerpc didn't support dynamic loading.  I'm not sure if any released
version of NetBSD/powerpc didn't support dynamic loading.  If all of them
did, then we should remove this check.

> Just highly confused (and since I'm trying to get the failure list down on
> my bulk builds fixing these would be nice).

The state of Python + extension modules in pkgsrc is ... poor.  Given how
our packages are currently structured, there is no way to use more recent
versions of python, and the python extension packages aren't flexible enough
to survive an upgrade of Python.  AFAICT, this is the reason why lang/python
is still at 2.0.1 while the 2.2 release is imminent.

This all needs to be fixed, but it's not obvious how to do so.  My feeling
is that the python packages can be structured like the perl or php packages,
but I've to take a closer look at the whole thing.  If you can find some way
to use extension.buildlink.mk with those problematic packages, it will serve
us well in the meantime.

	Cheers,

	-- Johnny Lam <jlam@jgrind.org>