present - at least the swigged file should be named <name>_wrap.c as
this is also SWIG's default. (Even better would be to generate the
wrapped sources in a different location, but I'll leave this for
later).
Newer versions of SWIG don't accept the -dnone flag any more.
Since virtually nobody uses SWIG with distutils, this should do no
harm.
Suggested be Martin Bless on c.l.p.
crashes.
If no external zip-utility is found, the archive is created by the
zipfile module, which behaves different now than in 2.1: if the
zip-file is created in the root directory if the distribution, it will
contain an (empty) version of itself.
This triggered the above bug - so it's better to create the zip-file
far away in the TMP directory.
>
> When using 'distutils' (shipped with Python 2.1) I've found that my
> Python scripts installed with a first line of:
>
> #!/usr/bin/python2.1None
>
> This is caused by distutils trying to patch the first line of the python
> script to use the current interpreter.
distutils for the library modules built as shared objects. A better solution
appears possible, but with the threat that the distutils becomes more
magical ("complex").
This closes SF bug #458343.
bdist_wininst doesn't use the NT SCHEME any more, instead
a custom SCHEME is used, which is exchanged at installation
time, depending on the python version used.
Avoid a bogus warning frpom install_lib about installing
into a directory not on sys.path.
modules and extensions on Windows is now $PREFIX/Lib/site-packages.
Includes backwards compatibility code for pre-2.2 Pythons. Contributed
by Paul Moore.
libraries. This is done by adding a .get_source_files() method,
contributed by Rene Liebscher and slightly modified.
Remove an unused local variable spotted by PyChecker
though 'licence' is still supported for backward-compatibility
(Should I add a warning to get_licence(), or not bother?)
Also fixes an UnboundLocalError noticed by PyChecker
to the current Python interpreter (ie. the one used for
building/installation), even (especially!) if "/usr/bin/env" appears in
the #! line.
Rationale: installing scripts with "#!/usr/bin/env python" is asking for
trouble, because
1) it might pick the wrong interpreter (not the one used to
build/install the script)
2) it doesn't work on all platforms (try it on IRIX 5, or on Linux
with command-line options for python)
3) "env" might not be in /usr/bin