SWIG+Distutils - no harmony?

38 views
Skip to first unread message

Martin Bless

unread,
Jan 15, 2002, 3:26:05 PM1/15/02
to
Getting courageous I try building 'example.pyd'
from the SWIG 'Simple Example' using SWIG and the Distutils.
Looks promising but doesn't succeed. I didn't
modify 'example.c' and 'example.i'.

Problems/questions:

(1) Is 'setup.py' ok?
(2) BEWARE: What's really shocking:
After see (unsuccessful)
python setup.py build -cmingw32
the original 'example.c' is GONE AND AWAY -
replaced by the wrapper.
(3) What's going wrong?

Martin

Sources und logs following:

>----------<>----------<>----------<
# setup.py
# mb: Is this ok?
import distutils
from distutils.core import setup, Extension
#from distutils.extension import Extension

setup(name = "Example 'Simple' from the SWIG examples",
version = "2.2",
ext_modules = [Extension("example", ["example.i"])])

>----------<>----------<>----------<
/* File : example.i */
%module example

extern int gcd(int x, int y);
extern double Foo;

>----------<>----------<>----------<
/* File : example.c */

/* A global variable */
double Foo = 3.0;

/* Compute the greatest common divisor of positive integers */
int gcd(int x, int y) {
int g;
g = y;
while (x > 0) {
g = x;
x = y % x;
y = g;
}
return g;
}

>----------<>----------<>----------<
C:\python
Python 2.2 (#28, Dec 21 2001, 12:21:22) [MSC 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>>

>----------<>----------<>----------<
swig -version

SWIG Version 1.3.10u-20011211-2004
Copyright (c) 1995-1998
University of Utah and the Regents of the University of California
Copyright (c) 1998-2001
University of Chicago

Compiled with CC

>----------<>----------<>----------<
>python setup.py build -cmingw32

running build
running build_ext
building 'example' extension
swigging example.i to example.c
c:\pyext\swig\swig.exe -python -dnone
-ISWIG -o example.c example.i
c:\mingw\bin\gcc.exe -mno-cygwin -mdll
-O -Wall -IC:\PYTHON22\include
-c example.c -o build\temp.win32-2.2\Release\example.o
writing build\temp.win32-2.2\Release\example.def

c:\mingw\bin\gcc.exe -mno-cygwin -mdll -static
-s build\temp.win32-2.2\Release\example.o
build\temp.win32-2.2\Release\example.def
-LC:\PYTHON22\libs -lpython22
-o build\lib.win32-2.2\example.pyd

swig: Warning. -dnone option deprecated.

example.c: In function `SWIG_UnpackData':
example.c:363: warning: `uu' might be used uninitialized in this
function
example.c: In function `SWIG_ConvertPtr':
example.c:429: warning: suggest explicit braces to avoid ambiguous
`else'
example.c:432: warning: suggest explicit braces to avoid ambiguous
`else'
example.c:438: warning: suggest explicit braces to avoid ambiguous
`else'
example.c: At top level:
example.c:154: warning: `SWIG_TypeQuery' defined but not used
example.c:385: warning: `SWIG_ConvertPtr' defined but not used
example.c:468: warning: `SWIG_ConvertPacked' defined but not used
example.c:537: warning: `SWIG_MakeShadow' defined but not used
build\temp.win32-2.2\Release\example.o(.text+0xbda):example.c:
undefined reference to `gcd'
build\temp.win32-2.2\Release\example.o(.text+0xc35):example.c:
undefined reference to `Foo'
build\temp.win32-2.2\Release\example.o(.text+0xc6b):example.c:
undefined reference to `Foo'
build\temp.win32-2.2\Release\example.o(.text+0xc71):example.c:
undefined reference to `Foo'
error: command 'gcc' failed with exit status 1

>----------<>----------<>----------<

Thomas Heller

unread,
Jan 16, 2002, 5:54:17 AM1/16/02
to
"Martin Bless" <m.b...@gmx.de> wrote in message news:3c459006...@news.muenster.de...

> Getting courageous I try building 'example.pyd'
> from the SWIG 'Simple Example' using SWIG and the Distutils.
> Looks promising but doesn't succeed. I didn't
> modify 'example.c' and 'example.i'.
>
> Problems/questions:
>
> (1) Is 'setup.py' ok?

Your files are ok.

> (2) BEWARE: What's really shocking:
> After see (unsuccessful)
> python setup.py build -cmingw32
> the original 'example.c' is GONE AND AWAY -
> replaced by the wrapper.
> (3) What's going wrong?

A distutils bug. Support for SWIG is rather poor.
SWIGging a file <pathname>.i creates a file <pathname>.c
overwriting any previous file of this name. So better
change another name.

Thomas


Martin Bless

unread,
Jan 16, 2002, 6:40:16 AM1/16/02
to
[Thomas Heller]:

>A distutils bug. Support for SWIG is rather poor.
>SWIGging a file <pathname>.i creates a file <pathname>.c
>overwriting any previous file of this name. So better
>change another name.

Aha. Ok, I'll try to find a solution.

Which brings up two questions I carry around for a while:

(1) PythonWin: I can't find a way to cancel execution if I was clever
enough to produce an indefinite loop (ctrl+c, ctrl+z, ctrl+halt, ...
nothing I tried worked.

(2) Is there a way to include a stable and static breakpoint in Python
SOURCE while debugging, something like a "suspend" command, that make
introspection and a resume possible?

Martin

Simon Brunning

unread,
Jan 16, 2002, 6:48:05 AM1/16/02
to
> From: m.b...@gmx.de [SMTP:m.b...@gmx.de]

> (1) PythonWin: I can't find a way to cancel execution if I was clever
> enough to produce an indefinite loop (ctrl+c, ctrl+z, ctrl+halt, ...
> nothing I tried worked.

You'll find a Python icon in the system tray. Right click on this, and
select 'Break into running code'.


> (2) Is there a way to include a stable and static breakpoint in Python
> SOURCE while debugging, something like a "suspend" command, that make
> introspection and a resume possible?

Are you talking about a breakpoint? If so, it varies from debugger to
debugger. In PythonWin, hit F9 in the line where you want to break, and make
sure that you activate the debugger when you run your script.

Cheers,
Simon Brunning
TriSystems Ltd.
sbru...@trisystems.co.uk


-----------------------------------------------------------------------
The information in this email is confidential and may be legally privileged.
It is intended solely for the addressee. Access to this email by anyone else
is unauthorised. If you are not the intended recipient, any disclosure,
copying, distribution, or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful. TriSystems Ltd. cannot
accept liability for statements made which are clearly the senders own.

Piet van Oostrum

unread,
Jan 16, 2002, 7:50:52 AM1/16/02
to
>>>>> m.b...@gmx.de (Martin Bless) (MB) writes:

MB> [Thomas Heller]:


>> A distutils bug. Support for SWIG is rather poor.
>> SWIGging a file <pathname>.i creates a file <pathname>.c
>> overwriting any previous file of this name. So better
>> change another name.

MB> Aha. Ok, I'll try to find a solution.

MB> Which brings up two questions I carry around for a while:

MB> (1) PythonWin: I can't find a way to cancel execution if I was clever
MB> enough to produce an indefinite loop (ctrl+c, ctrl+z, ctrl+halt, ...
MB> nothing I tried worked.

There is an icon in the iconbar to break into the code.
--
Piet van Oostrum <pi...@cs.uu.nl>
URL: http://www.cs.uu.nl/~piet [PGP]
Private email: P.van....@hccnet.nl

Steve Holden

unread,
Jan 16, 2002, 8:00:37 AM1/16/02
to
"Martin Bless" <m.b...@gmx.de> wrote in message
news:3c4564ea...@news.muenster.de...

> [Thomas Heller]:
>
> >A distutils bug. Support for SWIG is rather poor.
> >SWIGging a file <pathname>.i creates a file <pathname>.c
> >overwriting any previous file of this name. So better
> >change another name.
>
> Aha. Ok, I'll try to find a solution.
>
> Which brings up two questions I carry around for a while:
>
> (1) PythonWin: I can't find a way to cancel execution if I was clever
> enough to produce an indefinite loop (ctrl+c, ctrl+z, ctrl+halt, ...
> nothing I tried worked.
>
Well, in this case there's a neat little systray icon that you can
right-mouse-button over. THe two context menu items are "Activate" and
"Break into running code". You want the second one!

regards
Steve
--
http://www.holdenweb.com/

Martin Bless

unread,
Jan 16, 2002, 10:59:48 AM1/16/02
to
Simon Brunning <SBru...@trisystems.co.uk> wrote:

>Are you talking about a breakpoint? If so, it varies from debugger to
>debugger. In PythonWin, hit F9 in the line where you want to break, and make
>sure that you activate the debugger when you run your script.

Yes, I'm looking for a PERSISTENT breakpoint. The F9 method is great
but in more complex projects I'd like to have persistent breakpoints
too.

What I'm missing is the "set step on" directive of FoxPro which
suspends execution. You can then manually inspect/modify whatever you
want and later on "resume" execution.

So, what I'm looking for is a function like

win32ui.PythonWinPleaseHearMyPlea(
"suspend here as if F9 was pressed")

To resume later on I could press F5 as usual.

Martin

Simon Brunning

unread,
Jan 16, 2002, 11:07:57 AM1/16/02
to
> From: m.b...@gmx.de [SMTP:m.b...@gmx.de]

> Yes, I'm looking for a PERSISTENT breakpoint. The F9 method is great
> but in more complex projects I'd like to have persistent breakpoints
> too.
>
> What I'm missing is the "set step on" directive of FoxPro which
> suspends execution. You can then manually inspect/modify whatever you
> want and later on "resume" execution.
>
> So, what I'm looking for is a function like
>
> win32ui.PythonWinPleaseHearMyPlea(
> "suspend here as if F9 was pressed")
>
> To resume later on I could press F5 as usual.

OK, try this:

import pywin.debugger
pywin.debugger.brk()

Fernando Pérez

unread,
Jan 15, 2002, 6:54:16 AM1/15/02
to
Martin Bless wrote:

> (2) Is there a way to include a stable and static breakpoint in Python
> SOURCE while debugging, something like a "suspend" command, that make
> introspection and a resume possible?
>
> Martin

Take a look at my IPython project: http://www-hep.colorado.edu/~fperez/ipython

It gives you a ready to embed interpreter. You can simply go as follows:

... your code...
IPython.embed() -> code stops and opens an interpreter which sees the state
of your code. You can see variables, print, etc. All your vars and functions
are available. When done, hit Ctrl-D as usual to terminate.
... your code continues.

You could put the embed() calls in an

if DEBUG:

and globally turn them on/off easily.

hth,

f.

Martin Bless

unread,
Jan 16, 2002, 5:24:00 PM1/16/02
to
[Simon Brunning <SBru...@trisystems.co.uk>]:

>OK, try this:
>
>import pywin.debugger
>pywin.debugger.brk()

Great, thank you very much, it's exactly what I was looking for. It
already helped with some distutils investigations. Here's how I use it
- looks very familiar to me and can easily be "grep'd":

#at beginning of module:
MBDEBUG = 1 # or 0
if MBDEBUG:
from pywin.debugger import brk as set_step_on

#wherever I need a persistent breakpoint:

if MBDEBUG:
set_step_on()

Now feeling much stronger when fighting bugs

Martin


Martin Bless

unread,
Jan 16, 2002, 5:25:11 PM1/16/02
to
["Thomas Heller" <thomas...@ion-tof.com>]:

>A distutils bug. Support for SWIG is rather poor.
>SWIGging a file <pathname>.i creates a file <pathname>.c
>overwriting any previous file of this name. So better
>change another name.

It's working now. Here's what I changed to get things going:

>----------<>----------<>----------<
I changed two lines in distutils.command.build_ext.py

(1) in function
def swig_sources (self, sources):
[...]
#new_sources.append(base + target_ext) #old
new_sources.append(base + '_wrap' + target_ext) #new

This prevents the C-source from getting overwritten.
Adding '_wrap' to the base is the naming convention SWIG 1.3 employs
anyway if not told otherwise.

(2) I use a different SWIG commandline. Second change:

#swig_cmd = [swig, "-python", "-dnone", "-ISWIG"] #old
swig_cmd = [swig, "-python"] #new

>----------<>----------<>----------<
# 3. change: added "example.c" to extension list
#
# setup.py


import distutils
from distutils.core import setup, Extension

setup(name = "Example 'Simple' from the SWIG examples",
version = "2.2",
ext_modules = [Extension("example", ["example.i","example.c"])])

>----------<>----------<>----------<

Thankful,

Martin

PS: ... and yes, the docs are poor or outdated. The SWIG doc about
Python is from 1997 and deals with Python 1.3 and 1.4. Feels like an
ancient millenium ;-)

Mark Hammond

unread,
Jan 16, 2002, 10:27:49 PM1/16/02
to
Martin Bless wrote:

> (2) Is there a way to include a stable and static breakpoint in Python
> SOURCE while debugging, something like a "suspend" command, that make
> introspection and a resume possible?


For the Pythonwin debugger, you can add:

import pywin.debugger
pywin.debugger.brk()

This should work from almost any Python script.

Mark.

Bruce Dawson

unread,
Jan 17, 2002, 12:19:17 AM1/17/02
to
You could also try the recently released HapDebugger. It has a
break->now command in the menus. The main advantage of the
HapDebugger implementation is it lets you resume after
you've broken.

Thomas Heller

unread,
Jan 17, 2002, 2:47:53 AM1/17/02
to

"Martin Bless" <m.b...@gmx.de> wrote in message news:3c48fd83...@news.muenster.de...

> ["Thomas Heller" <thomas...@ion-tof.com>]:
> >A distutils bug. Support for SWIG is rather poor.
> >SWIGging a file <pathname>.i creates a file <pathname>.c
> >overwriting any previous file of this name. So better
> >change another name.
>
> It's working now. Here's what I changed to get things going:
>
> >----------<>----------<>----------<
> I changed two lines in distutils.command.build_ext.py
[snip]

These changes look good, but you could even do this without
changing the disutils sources by subclassing build_ext inside your
setup script and override some methods with your fixes:

from distutils.command.build_ext import build_ext

class my_build_ext(build_ext):
def swig_sources(self, sources):


[...]
#new_sources.append(base + target_ext) #old
new_sources.append(base + '_wrap' + target_ext) #new

[...]


#swig_cmd = [swig, "-python", "-dnone", "-ISWIG"] #old
swig_cmd = [swig, "-python"] #new

[...]

Then you instruct duistutils to use your "my_build_ext" class
instead of the buildin build_ext class. In the call to the setup
function supply a cmdclass parameter:

setup(
[...]
cmdclass = {'build_ext': my_build_ext, },
[...]
)

Thomas


Skip Montanaro

unread,
Jan 17, 2002, 12:43:00 PM1/17/02
to

Thomas> These changes look good, but you could even do this without
Thomas> changing the disutils sources by ...

Shouldn't the default be to do the right thing? Otherwise every author
publishing applications that use SWIG will have to solve the same problem.

--
Skip Montanaro (sk...@pobox.com - http://www.mojam.com/)

Thomas Heller

unread,
Jan 17, 2002, 4:14:40 PM1/17/02
to
"Skip Montanaro" <sk...@pobox.com> wrote in message news:mailman.1011289468...@python.org...

>
> Thomas> These changes look good, but you could even do this without
> Thomas> changing the disutils sources by ...
>
> Shouldn't the default be to do the right thing? Otherwise every author
> publishing applications that use SWIG will have to solve the same problem.


You're right - it should be fixed in distutils (if I understand you
correctly ;-)

Thomas


Thomas Heller

unread,
Jan 18, 2002, 4:16:31 PM1/18/02
to
"Martin Bless" <m.b...@gmx.de> wrote in message news:3c48fd83...@news.muenster.de...

> It's working now. Here's what I changed to get things going:
>
> >----------<>----------<>----------<
> I changed two lines in distutils.command.build_ext.py
>
> (1) in function
> def swig_sources (self, sources):
> [...]
> #new_sources.append(base + target_ext) #old
> new_sources.append(base + '_wrap' + target_ext) #new
>
> This prevents the C-source from getting overwritten.
> Adding '_wrap' to the base is the naming convention SWIG 1.3 employs
> anyway if not told otherwise.
>
> (2) I use a different SWIG commandline. Second change:
>
> #swig_cmd = [swig, "-python", "-dnone", "-ISWIG"] #old
> swig_cmd = [swig, "-python"] #new
>
> >----------<>----------<>----------<
Martin,

I've checked in exactly your changes.

Thanks,

Thomas


Niki Spahiev

unread,
Jan 19, 2002, 8:42:08 AM1/19/02
to
2002-01-18, 23:16:31, Thomas Heller wrote:

>>
>> (2) I use a different SWIG commandline. Second change:
>>
>> #swig_cmd = [swig, "-python", "-dnone", "-ISWIG"] #old
>> swig_cmd = [swig, "-python"] #new
>>
>> >----------<>----------<>----------<

TH> I've checked in exactly your changes.

TH> Thanks,

TH> Thomas


IMHO swig-cpp option should add -shadow after -c++. Should i send patches
somewhere?


--
Best regards,
Niki Spahiev


______________________________________
VEGA(TM) Internet Service Provider
<http://www.vega.bg>
Scanned and protected by Inflex
Tova pismo e provereno i zashtiteno
ot programite "Inflex/Antivir".

ruif...@gmail.com

unread,
Jul 7, 2018, 6:23:17 AM7/7/18
to
Reply all
Reply to author
Forward
0 new messages