The problem is in Distribute dependencies on Python 3. Create a new command
class instead of changing inplace the one other projects may use.
Close ticket #153.
Python versions 2.4 and 2.5 for MSVC on Windows do not need to manifest file
reinserted into the DLL. The VC compiler for these versions does not have the
mt.exe executable to insert the manifest file.
At init time, build_ext is not configured, so neither the --compiler option
nor settings in setup.cfg/distutil.cfg is effective.
Steve, I told you distutils was a mess :)
- Make sure to declare self.pg_config in initialize_options.
- Don't declare PostgresConfig in __init__, as its scope is limited.
- Pass build_ext instance to PostgresConfig to avoid having to
call the option parser directly.
- Don't override global variable name "ext" (use "extension" as function
argument names)
- Improve function naming (get_compiler -> get_compiler_name)
- Other misc operator spacing and 80-column violation cleanup.
- Remove unneeded import (DistUtilsFileError)
Previously we only checked for the existence of the include files, but this
doesn't imply the presence of the module. Particularly true in restricted
environments such as virtualenv.
Closes ticket #53.
The MSVC compiler sees a request for the main symbol (init__pyscopg) to be
exported twice during the build process and issues a warning in 64bit mode.
One symbol is from distutils exporting the library with the
build_ext.get_export_symbols() function, the other is from the #define
PyMODINIT_FUNC (define in pyport.h) that begins the main _psycopg module.
This patch overrides the get_export_symbols function and returns an empty
array of symbols to export if the compiler is MSVC.
Initial compiler check was only checking two python versions. Changed the
check not to check python version, but compiler version, to be compatible
with more versions of python.
Apparently, using * for the architecture has the potential to not work on
on some amd64 systems. Added checks and split the manifest based upon
architecture.
