Subject: Re: swig-python
To: None <tech-pkg@NetBSD.ORG>
From: Eric Gillespie <>
List: tech-pkg
Date: 08/25/2003 16:49:07
MLH <> writes:

> I have a local py-glpk package that I am attempting to update to
> a modern version of glpk. It requires an update to both glpk (which
> I have ready) and an update to swig.

Are you sure?  We have two versions of SWIG in pkgsrc right
now. the ancient SWIG 1.1 in devel/swig (which i intended to
rename to swig11 but ran out of time) and SWIG 1.3.17 in the
other devel/swig* packages.  This is only one version behind, and
is compatible with 1.3.19.  I haven't had a chance to upgrade it,
and since i have been using it with Subversion extensively for so
long, i haven't had much incentive.  If you have an updated
package though, it would be welcome.

> but I would like to determine the best os-independent method of
> accomplishing this.

I don't know about "best", but isn't SWIG the *only*
cross-plaform solution available other than generating your
binding by hand?

> What is the prevailing preference for using swig with python?
> Should I be trying to use swig-python, a python (what
> I currently use) or a std makefile (which would be easy also) ?

You are confusing two issues.  SWIG is a program for generating
bindings to C and C++ code in languages such as Python, Perl, and
Tcl.  distutils ( and make, however, are build tools.
The preference in the Python world is to use distutils, and for
good reasons covered on the Python web site and distutils
documentation.  Furthermore, you said "os-independent", which
distutils is and make is not.


Eric Gillespie <*>

Build a fire for a man, and he'll be warm for a day.  Set a man on
fire, and he'll be warm for the rest of his life. -Terry Pratchett