installed to build extensions. This patch makes distutils emit a warning when
the compiler should use an SDK but that SDK is not installed, hopefully reducing
some confusion.
universal build of python on OSX 10.3 to ensure that those flags can be used
to compile code (the universal build uses compiler flags that aren't supported
on 10.3). This patches gives the same treatment to CFLAGS, PY_CFLAGS and
BLDSHARED.
This patchs makes it possible to create a universal build on OSX 10.4 and use
the result to build extensions on 10.3. It also makes it possible to override
the '-arch' and '-isysroot' compiler arguments for specific extensions.
configure time. The current check is too strict and doesn't allow building
extensions that can only run on newer versions of the OS than the version
python was build for, that is python build for 10.3 or later and an extension
for 10.4. This patch relaxes this check.
This turned out to be a reimplementation of patch 1193190.
/path/to/uninstalled/python setup.py build_ext
now failed with pyconfig.h not found. Prior to r45232
the above command did not look for pyconfig.h, but the
bug is really in the look-up code: expecting to find it
in os.curdir is a rather fragile idea.
Bug #1160802: Can't build Zope on Windows w/ 2.4.1c1.
MSVCCompiler.initialize(): set self.initialized to True, as suggested
by AMK. Else we keep growing the PATH endlessly, with each new C
extension built, until putenv() complains.
No change to NEWS because the patch that created this bug is also new
for 2.5a1 (so there's no change here to any code yet released from HEAD).
to make using "-undefined dynamic_lookup" for linking extensions more
automatic on 10.3 and later. So if we're on that platform and
MACOSX_DEPLOYMENT_TARGET is not set we now set it to the current OSX
version during configure. Additionally, distutils will pick up the
configure-time value by default.
Will backport.
scripts without modifying either the distutils installation or the
setup.py scripts of packages with which the new commands will be used.
Specifically, an option is added to distutils that allows additional
packages to be searched for command implementations in addition to
distutils.command. The additional packages can be specified on the
command line or via the installation or personal configuration files
already loaded by distutils.
For discussion, see the thread starting with:
http://mail.python.org/pipermail/distutils-sig/2004-August/004112.html
This closes SF patch #102241.
Patch from Mark Hammond:
bdist_wininst attempts to use the correct MSVC runtime for the current
version of Python. This doesn't work correctly when --target-version
is set. In that case, bdist_wininst still uses the *current*
sys.version (ie, 2.4) rather than the version specified as
--target-version. Thus, the msvc7 runtime based executable stub is
*always* used.
This patch "hard-codes" knowledge of earlier Python versions,
providing the correct result when Python 2.4 is used to build Python
2.3 and earlier distributions.
Remove the short variant (-v) of the --target-version command line
options, it conflicts with the --verbose/-v standard distutils switch.
This is basically the support for package data from Phillip Eby's
setuptools package. I've changed it only to fit it into the core
implementation rather than to live in subclasses, and added
documentation.
of hard linking against the framework).
If $MACOSX_DEPLOYMENT_TARGET is set, and >= 10.3, during configure we
setup extensions to link with dynamic lookup. We also record the
value in the Makefile.
Distutils checks whether a value for MACOSX_DEPLOYMENT_TARGET was
recorded in the Makefile, and if it was insists that the current
value matches.
This is only a partial fix because it only applies to 2.4, and the
"two python problem" exists with Python 2.3 shipped with MacOSX 10.3,
which we have no influence over.
requires and provides. requires is a sequence of strings, of the
form 'packagename-version'. The dependency checking so far merely
does an '__import__(packagename)' and checks for packagename.__version__
You can also leave off the version, and any version of the package
will be installed.
There's a special case for the package 'python' - sys.version_info
is used, so
requires= ( 'python-2.3', )
just works.
Provides is of the same format as requires - but if it's not supplied,
a provides is generated by adding the version to each entry in packages,
or modules if packages isn't there.
Provides is currently only used in the PKG-INFO file. Shortly, PyPI
will grow the ability to accept these lines, and register will be
updated to send them.
There's a new command 'checkdep' command that runs these checks.
For this version, only greater-than-or-equal checking is done. We'll
add the ability to specify an optional operator later.
msvccompiler.get_build_version().
Distributions without a pre-install-script didn't work any longer, we
must at least provide the terminating NUL character.
included in Python distributions for systems other than Windows.
Windows installers can be build on non-Windows systems as long as they
only include pure python module distributions.
Patch #892660 from Mark Hammond, for distutils bdist_wininst command.
install.c: support for a 'pre-install-script', run before anything has
been installed. Provides a 'message_box' module function for use by
either the pre-install or post-install scripts.
bdist_wininst.py: support for pre-install script. Typo (build->built),
fixes so that --target-version can still work, even when the
distribution has extension modules - in this case, we insist on
--skip-build, as we still can't actually build other versions.
install.c: support for a 'pre-install-script', run before anything has
been installed. Provides a 'message_box' module function for use by
either the pre-install or post-install scripts.
bdist_wininst.py: support for pre-install script. Typo (build->built),
fixes so that --target-version can still work, even when the
distribution has extension modules - in this case, we insist on
--skip-build, as we still can't actually build other versions.
Use case: Sometimes 'compiling' source files (with SWIG, for example)
creates additionl files which included by later sources. The win32all
setup script requires this.
There is no SF item for this, but it was discussed on distutils-sig:
http://mail.python.org/pipermail/distutils-sig/2003-November/003514.html
distutils now looks for the compiler version in sys.version, falling
back to MSVC 6 if the version isn't listed (Python 2.2 and lower).
Add helper routines for reading the registry. Refactor many
module functions into methods of the compiler to avoid passing
lots of state as arguments.
On cygwin, the setup.py script uses unixccompiler.py for compiling and linking
C extensions. The unixccompiler.py script assumes that executables do not get
special extensions, which makes sense for Unix. However, on Cygwin,
executables get an .exe extension.
This causes a problem during the configuration step (python setup.py config),
in which some temporary executables may be generated. As unixccompiler.py does
not know about the .exe extension, distutils fails to clean up after itself: it
does not remove _configtest.exe but tries to remove _configtest instead.
The attached patch to unixccompiler.py sets the correct exe_extension for
cygwin by checking if sys.platform is 'cygwin'. With this patch, distutils
cleans up after itself correctly.
Michiel de Hoon
University of Tokyo, Human Genome Center.
After some more reflection (and no negative feedback), I am reverting the
original patch and applying my version, cygwinccompiler.py-shared.diff,
instead.
My reasons are the following:
1. support for older toolchains is retained
2. support for new toolchains (i.e., ld -shared) is added
The goal of my approach is to avoid breaking older toolchains while adding
better support for newer ones.
The cygwinccompiler.get_versions() function only handles versions numbers of
the form "x.y.z". The attached patch enhances get_versions() to handle "x.y"
too (i.e., the ".z" is optional).
This change causes the unnecessary "--entry _DllMain@12" link option to be
suppressed for recent Cygwin and Mingw toolchains. Additionally, it directs
recent Mingw toolchains to use gcc instead of dllwrap during linking.
Currently, the cygwinccompiler.py compiler handling in
distutils is invoking the cygwin and mingw compilers
with the -static option.
Logically, this means that the linker should choose to
link to static libraries instead of shared/dynamically
linked libraries.
Current win32 binutils expect import libraries to have
a .dll.a suffix and static libraries to have .a suffix.
If -static is passed, it will skip the .dll.a
libraries. This is pain if one has a tree with both
static and dynamic libraries using this naming
convention, and wish to use the dynamic libraries.
The -static option being passed in distutils is to get
around a bug in old versions of binutils where it would
get confused when it found the DLLs themselves.
The decision to use static or shared libraries is site
or package specific, and should be left to the setup
script or to command line options.
specified with an absolute path, the object file is also
written to an absolute path. The patch drops the drive and
leading '/' from the source path, so a path like /path/to/foo.c
results in an object file like build/temp.i686linux/path/to/foo.o.
bdist_wininst.py we will see.)
Removed the base64 encoded binary contents, wininst.exe must be in the
same directory as this file now.
wininst.exe must be recompiled and commited each time the sources in
PC/bdist_wininst are changed.
Previously archive_util.py attempted to spawn an
external 'zip' program for the zip action, if this fails, an
attempt to import zipfile.py is made...
This bites folks who have 'old' or non-conforming zip
programs on windows platforms. This change tries the 'zipfile'
module first, falling back to spawning a zip process if
the module isn't available.