the Cygwin-specific compiler class.
(According to Jason Tishler, cygwinccompiler needs some work to
handle the differences in Cygwin- and MSVC-Python. Makefile and
config files are currently ignored by cygwinccompiler, as it was
written to support cygwin for extensions which are intended to be
used with the standard MSVC built Python.)
and also takes the sys.platform name into account. This helps on
platforms where there are multiple possible compiler backends (the
one with which Python itself was compiled is preferred over others
in this case).
The patch uses this new technique to enable using cygwin compiler
per default for cygwin compiled Pythons.
Written by Marc-Andre Lemburg. Copyright assigned to Guido van Rossum.
implementations. Details:
* replace 'link_shared_object()', 'link_shared_lib()', and
'link_executable()' with 'link()', which is (roughly)
the union of the three methods it replaces
* in all implementation classes (UnixCCompiler, MSVCCompiler, etc.),
ditch the old 'link_*()' methods and replace them with 'link()'
* in the abstract base class (CCompiler), add the old 'link_*()'
methods as wrappers around the new 'link()' (they also print
a warning of the deprecated interface)
Also increases consistency between MSVCCompiler and BCPPCompiler,
hopefully to make it easier to factor out the mythical WindowsCCompiler
class. Details:
* use 'self.linker' instead of 'self.link'
* add ability to compile resource files to BCPPCompiler
* added (redundant?) 'object_filename()' method to BCPPCompiler
* only generate a .def file if 'export_symbols' defined
methods (but not 'link_executable()', hmmm). Currently only used by
BCPPCompiler; it's a dummy parameter for UnixCCompiler and MSVCCompiler.
Also added 'bcpp' to compiler table used by 'new_compiler()'.
that a particular compiler system depends on. This consists of the
'set_executables()' and 'set_executable()' methods, and a few lines in
the constructor that expect implementation classes to provide an
'executables' attribute, which we use to initialize several instance
attributes. The default implementation is somewhat biased in favour of
a Unix/DOS "command-line" view of the world, but it shouldn't be too
hard to override this for operating systems with a more sophisticated
way of representing programs-to-execute.
it in UnixCCompiler. Still needs to be implemented in MSVCCompiler (and
whatever other compiler classes are lurking out there, waiting to be
checked in).
values that "--foo" can take for various commands: eg. what formats for
"sdist" and "bdist", what compilers for "build_ext" and "build_clib".
I have *not* reviewed this patch; I'm checking it in as-is because it also
fixes a paper-bag-over-head bug in bdist.py, and because I won't have
time to review it properly for several days: so someone else can
test it for me, instead!
Split '_fix_link_args()' up into '_fix_object_args()' (for use of
'create_static_lib() and link methods) and '_fix_lib_args()' (for the
link methods only).
option in the 'build_ext' command):
* in ccompiler.py: 'gen_lib_options()' now takes 'runtime_library_dirs'
parameter
* in unixccompiler.py and msvccompiler.py: now pass
'self.runtime_library_dirs' to 'gen_lib_options()', and define
'runtime_library_dir_option()' (although in msvccompiler.py it
blows up with a DistutilsPlatformError right now!)
implement it (so far):
* moved filename generation methods into CCompiler base class,
driven by data supplied by implementation classes
* moved a bunch of common code from UnixCCompiler to convenience
methods in CCompiler
* overhauled MSVCCompiler's compile/link methods to look and act
as much as possible like UnixCCompiler's, in order to regularize
both interface and behaviour (especially by using those new
convenience methods)
has a directory component, then we only search for the library in
that one directory, ie. ignore the 'library_dirs' lists for that
one library.
Changed calling convention to 'gen_lib_options()' again: now, it takes
a CCompiler instance and calls methods on it instead of taking
format strings. Also implemented the new "library name" semantics
using the 'find_library_file()' method in the CCompiler instance.
Added 'force' flag to CCompiler; added to constructor and 'new_compiler()'.
Added 'warn()' method.
which allowed us to get rid of the 'build_info' used in some places
(a temporary kludge to support MSVC++ "def" files).
Deleted big comment whining about that kludge.
Added 'compiler_type' class attribute.
Overhauled 'new_compiler()': now takes 'compiler' argument along with
'plat' (both optional with sensible defaults), and looks them both up
in the new 'default_compiler' and 'compiler_class' dictionaries to
figure out where to get the concrete compiler class from.
Reordered arguments to 'gen_lib_options()' to match the order in
which the arguments are generated (ie. -L before -l).
Added big comment about the kludginess of passing 'build_options'
to the link methods and how to fix it.
Added 'gen_preprocess_options()' and 'gen_lib_options()' convenience
functions -- the two cases are very similar for Unix C Compilers and
VC++, so I figured I might as well unify the implementations.
- fix some broken abstract methods
- kludge: add 'build_info' parameter to link methods
- add 'object_name()' and 'shared_library_name()'
- support for MSVCCompiler class on NT/Win95
'new_compiler()' factory function.
Added 'runtime_library_dirs' list (for -R linker option) and methods
to manipulate it.
Deleted some obsolete comments.
Added all the filename manglign methods: 'object_filenames()',
'shared_object_filename()', 'library_filename()',
'shared_library_filename()'.
Added 'spawn()' method (front end to the "real" spawn).
Jack Jansen
Andrew M. Kuchling
Marc-André Lemburg
Greg Ward
Jeremy Hylton