I just installed swig 1.3.6 (development version) and it no longer
appears to support the "-dnone" option used by distutils:
swigging src/bnc.i to src/bnc.c
swig -python -dnone -ISWIG -o src/bnc.c src/bnc.i
swig error : Unrecognized option -dnone
Use 'swig -help' for available options.
error: command 'swig' failed with exit status 1
One block of code I added to my setup.py script is to check whether
swig is present on a system. If it's available, swig the interface
files, otherwise skip the swig step and build the .c files present in
the distribution. (Unfortunately, everything fails if swig is present
but chokes on the command line you give it.)
Conditional swig invocation would be a great feature to add to distutils.
From: Robin Becker [mailto:firstname.lastname@example.org]
> does this PEP address the location of .pyds and associated .dlls
> under win32?
Yes. Read the PEP. It addresses it, by saying that nothing special will be
> If I have several separate extensions which depend on common .dlls there
> is always a problem under win32 if they go into separate areas. As I
> understand it if the dll is in the same directory as the pyd that uses
> it then all's well.
The PEP doesn't address this problem - if it's a problem now, it won't be
fixed by the PEP. All the PEP does is make PYTHONROOT\lib\site-packages the
"preferred" location, instead of the current PYTHONROOT. Do you currently
put DLLs in PYTHONROOT? Probably not.
> I have no objection to dlls and .dlls ending up in PYTHONROOT\lib\site-
> packages, but what about the associated .libs (for dlls/pyds) and real
> static .libs and where are we to install include files for exported
> apis. I haven't any objection to following the unix model as closely as
> possible, but what really stands out here is that the base install has
> its own special directories for DLLs and Libs etc. The extensions are
> really just extensions and could theoretically be installed or not.
This is a valid issue, appropriate for consideration by the distutils-sig,
but it doesn't affect PEP 250. That PEP just alters the "root" location from
which a distributed package should hang. It doesn't have anything to say
about the internal organisation of that distribution, or about how the
distribution manages to locate its resources (DLLs, documentation, resource
files, whatever else).
Hope this helps,