Oscar Benjamin added the comment:
On 22 May 2013 12:43, Martin v. Löwis <rep...@bugs.python.org> wrote:
> Am 21.05.13 23:14, schrieb Oscar Benjamin:
>> More generally I think that compiling non-cygwin extensions with
>> cygwin gcc should be altogether deprecated (for Python 3.4 at least).
>> It should be discouraged in the docs and unsupported in the future.
>
> I agree with that,
Excellent.
> although I find it sad that the Cygwin project
> apparently abandoned support for building Mingw binaries.
I don't understand their reasoning but given the scorn poured on to
-mno-cygwin from at least some people I trust that they had some good
reason :)
Also they have replaced it with something that they consider more
appropriate (the cross-compilers).
>> It can only work with -mno-cygwin
>
> This is factually incorrect. It also works with the i686-pc-mingw32-gcc
> executable, which (IIUC) is still available for Cygwin.
I should have been slightly clearer. It can only currently work in
distutils with -mno-cygwin. The executable you refer to is part of
cygwin gcc's cross-compiler toolchain. This is their recommended
replacement for -mno-cygwin (if not mingw) but is AFAICT unsupported
by distutils.
I think there's a case for saying that distutils should support these
but it should only be done with a new UnixCCompiler subclass and a new
--compiler entry point. It should also perhaps provide a way to
specify the --host since I think that facility is part of the purpose
of the new toolchain.
In any case cygwin cross-compiler support should not be conflated in
the codebase with distutils' mingw support and if it is to be added
that should be discussed in a separate issue. I personally don't think
I would use it and would not push for the support to be added.
Going back to the group C users: I think that it should be possible to
create an is_cygwingcc() function that would parse the output of 'gcc
--version'. Then Mingw32CCompiler.__init__ could do:
if is_cygwingcc() and self.gcc_version >= '4':
raise RuntimeError('No cygwin mode only works with gcc-3. Use
gcc-3 or mingw')
The is_cygwingcc() function can be conservative since false positives
or more of a problem than false negatives. I think this should address
your concern.
However on further reflection I'm a little reluctant to force an error
if I can't *prove* that the setup is broken. I'm no stranger to
monkey-patching distutils and it's possible that someone has already
monkey-patched it to make some bizarre setup just about work. I would
be a little peeved if my setup broke in a bugfix release simply
because someone else who didn't understand it decided that it wasn't
viable. (The same monkey-patching concerns apply to the other changes
but I think that fixing the non-monkey-patched setup for mingw trumps
in that case.) So perhaps the best place to deal with the
gcc-4/no-cygwin issue is in the distutils docs.
My updated proposal is (I'll write patches if this is acceptable):
Python 3.4:
Remove '-mno-cygwin'. This breaks the no-cygwin mode and fixes the
mingw mode. The distutils docs are updated with something like:
'''
Note: Previous Python versions supported another 'no-cygwin' mode that
could use cygwin gcc to build extensions without a dependency on
cygwin.dll. This is no longer supported.
New in Python 3.4: No-cygwin mode is no longer supported.
'''
Python 2.7, 3.2 and 3.3:
Only use '-mno-cygwin' if self.gcc_version < '4'. This should not
break any currently functioning setups (barring serious
monkey-patching). The distutils docs are updated with something like:
'''
Note: The no-cygwin mode only works with cygwin's gcc-3. For gcc-4 it
may produce .pyd files with dependencies on cygwin.dll that are not
fully redistributable. The use of no-cygwin mode is deprecated by
cygwin and support for it is removed in Python 3.4.
'''
If you would rather have the is_cygwingcc() check I'm happy to put
that in also if it gets this issue moving but I'm personally cautious
about it.
Thanks,
Oscar
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue12641>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
