gmane.comp.gnu.mingw.user

Re: Fixing mingw support in Python's distutils

Roumen Petrov — 2013-05-25T15:54:24

Please review in details how distutils work and lets remove "ugly hacks 
" exiting into current python code.



This is just because python refuse to fix issues related to cygwin and 
mingw.
Note that exist issue open before 10(!) years.
It seems to that leaving mingw related issues unfixed is intentionall.


Roumen


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-25T15:19:41

On 25 May 2013 15:05, Keith Marshall
<keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org> wrote:

Because fixing that while still using the same --compiler=mingw32 will
require more ugly hacks and make it even more difficult to solve these
kinds of problems in future. The real fix would be to have a separate
CCompiler class for the Cygwin cross-compilers that is activated by
--compiler=cygwin-cross or similar. The fact that Cygwin's new
cross-compilers currently don't work provides the opportunity to make
that change without backwards compatibility concerns and I believe it
could get accepted into Python 3.4. However I don't expect that the
same change would be accepted in the other Python versions (It's
really not up to me).


I am interested in fixing a long-broken actually used setup that has
been complained about repeatedly by many different users including
myself. I have never seen anyone complain about the lack of support
for Cygwin's new cross compilers and no one has opened an issue on t

Re: Fixing mingw support in Python's distutils

Roumen Petrov — 2013-05-25T14:25:41

Yet another person why try to use word "frozen" and to reject support 
for gcc windows compilers in python.
"distutils is frozen" is related to another issue and I cannot 
understand how a set of patches that keep API compatibility an be 
categorized as breakage.

:) Please setup various build environment and try create a simple python 
extension module written in "C".

My patch restore support to level as it was before.
Please note that gcc with -mno-cygwin is cross-compiler !!!!


Roumen


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX

Re: Fixing mingw support in Python's distutils

Keith Marshall — 2013-05-25T14:05:48

Why not?  You're *not* adding a new feature; you're just proposing to 
fix an existing one, which is broken.


The reality is that you're not really interested in fixing anything at 
all; the beast is terminally ill, so you may as well just let it die.

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-25T12:40:51

Please ask this question on the tracker not here. Your patches change
too many things; distutils is frozen and will not be overhauled. If
you want a patch to be accepted you should make a minimal patch that
fixes a specific issue.

Also IMO the cross-compilers should use a different --compiler entry
point. This design mistake (using --compiler=mingw32 with Cygwin's
gcc) is the root cause of issue 12641 and is the reason that it has
remained unfixed for 2 years. Your patches IIUC propose to extend this
poor design decision by allowing --compiler=mingw32 to be also used
for the new Cygwin cross-compilers.


Oscar

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/s

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-25T12:33:43

On 25 May 2013 07:23, Keith Marshall
<keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org> wrote:

I agree but...


Actually I think the robust choice is to have the user specify the
compiler they want to use.


I agree. I proposed to check the version simply because distutils
already does this and I'm trying to keep any patch as minimal as
possible to maximise the chance of acceptance (distutils is frozen).
You can see the code I'm trying to fix here:
http://hg.python.org/cpython/file/0bf4a6b56eb5/Lib/distutils/cygwinccompiler.py#l274


Neither do I :)

I must admit I'm a little frustrated by how drawn out this has become
but I'd just like to take this moment to thank you, Earnie, Paul and
everyone else in this thread for your help. It remains to be seen if I
can get this fixed but I certainly wouldn't have been able to do it
without your help.


Okay, so in distutils parlance
1) "Desired host" would be what the user gives for --compiler.
2) "Default compiler builds for cygwin host" means invoki

Re: which is better cross build or native build forwindows

Hardik Gohil — 2013-05-25T11:46:13

On Fri, May 24, 2013 at 4:43 PM, Keith Marshall

i want to go for crossbuild on ubuntu is it ok ?

sent me some link of website to follow cross-build
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://li

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-25T11:35:56

Because then if someone uses Cygwin gcc >= 4.6 with --compiler=mingw32
they might get a broken binary that depends on cygwin.dll (Actually
when I tried this I got strange compilation errors coming out of the
Python header files). I want to ensure that someone uses
--compiler=mingw32 with a version of Cygwin gcc that does not support
no-cygwin mode sees an error message that clearly shows they have the
wrong compiler.


Any particular package may depend on a particular version of MinGW
gcc. It is not the job of distutils to decide which versions are
generally acceptable. Although in practise the need to link against
the appropriate msvcrxx.dll means that you need a sufficiently new
version of MinGW for any given Python version.


Oscar

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor you

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-25T11:26:20

On 24 May 2013 20:58, Keith Marshall
<keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org> wrote:

This not about distutils on the Cygwin platform. Distutils has a
separate --compiler=cygwin that is used for building extension modules
for a Cygwin Python. In this case both Python and the extension module
are built by Cygwin's gcc and both link against cygwin.dll. When
someone builds extensions using a Cygwin Python this is what will
happen by default.

This issue is about someone who has a non-Cygwin Python built with
MSVC. The only officially supported compiler for this configuration is
the same version of MSVC that was used to build Python. However, you
can supply --compiler=mingw32 to use MinGW and if your MinGW is new
enough (and you patch distutils to remove -mno-cygwin) it will work.

Also, the demise of distutils on *all platforms* is assured; distutils
is broken by design. The long term fix is simply to stop using
distutils. Progress is being made on this front, most notably in the
form o

Re: Fixing mingw support in Python's distutils

Roumen Petrov — 2013-05-25T08:51:10

I think that flag was removed in 4.5 .

[SNIP]

Roumen

------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may
_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list etiquette may cause your account to be moderated.

_______________________________________________
You may change your MinGW Account Options or unsubscribe at:
https://lists.sourceforge.net/lists/listinfo/mingw-users
Also: mailto:mingw-users-request-5NWGOfrQmneRv

Re: Fixing mingw support in Python's distutils

Roumen Petrov — 2013-05-25T08:34:46

[SNIP]

And in current cygwin environment name of compiler for windows is
1) gcc-3.exe -mno-cygwin
2) i686-w64-mingw32-gcc.exe

And what is wrong with my set of patches ? Did you test them ?
Why you think that issue is not resolved yet with proposed set of updates ?

Did you build sample python extension in various environments including 
cygwin ?


[SNIP]

Please stop to add complexity to python build process.


Everything is resolved with my set of patches , including past , current 
and future mingw* compilers in native or posix environment.
As posix include cygwin and unix environments.


Regards,
Roumen


------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/

Re: Fixing mingw support in Python's distutils

Keith Marshall — 2013-05-25T06:23:25

Checking for specific versions of *any* tool is *always* a poor choice; 
it is a fragile mechanism, when what is really important is whether a 
specific *feature* is supported, or not.  The robust choice is *always* 
to check for feature support, directly.

It is *trivially* easy to check:

1) If the desired host to build for is mingw32.
2) If the current platform compiler builds for cygwin.
3) Given (1) and (2), if 'gcc -mno-cygwin' is a valid method of
    invoking a mingw32-gcc cross-compiler, or if it should be invoked
    as 'i686-pc-mingw32-gcc' (or whatever the appropriate name which
    has been chosen for the cross-compiler may be).

Checking each of these features is certainly no more difficult than 
checking for any specific minimum version of GCC, (which even then may 
*not* support -mno-cygwin anyway, even if it is <4.6 or whatever).  I 
really don't understand why this non-issue needs so much debate;
in pseudo-code:

   if desired host is mingw32
      if default compiler builds for cygwin hos

Re: Fixing mingw support in Python's distutils

Renato Silva — 2013-05-25T04:56:14

2013/5/24 Oscar Benjamin <oscar.j.benjamin-Re5JQEeQqe8AvxtiuMwx3w< at >public.gmane.org>

If -mno-cygwin has never been any harmful on MinGW, then why a simple GCC
version check would not work? That is, when --compiler=mingw32 and
gcc.version < 4.6 (assuming 4.6 is when it was removed), then add
-mno-cygwin to avoid the cygwin dependency.

Anyway, any reason to be so open about compiler versions? Pidgin, for
example, requires *MinGW* GCC, and more specifically, *version 4.4* (at the
moment). They have instructions on how to set it up, so I for example have
both  gcc 4.7 from MinGW and 4.4 from Pidgin build box living in peace
together.
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt!

Re: Fixing mingw support in Python's distutils

Keith Marshall — 2013-05-24T19:58:33

You should be.  Only if you do so, can you properly take control of the 
situation, to issue a *meaningful* diagnostic message, in the case when 
that necessary support is lacking.  Half hearted efforts to fix your 
issue, such as you advocate, pretty much assure the imminent demise of 
Python's distutils on the cygwin platform.


But you are trying to fix an existing cross-compiler solution, which 
happens to be incorrectly implemented.


... to invoke a *cross-compiler* which was, at one time, arcanely and 
improperly named; yes, 'gcc -mno-cygwin' *is* a (now defunct) name for a 
cygwin-hosted mingw32-gcc cross-compiler!  It's just that cygwin devs 
have now realised the error of their ways, have replaced that arcane 
naming convention, and now use standard naming.  Fixing the issue should 
be as simple as substituting the appropriate mingw32-gcc cross-compiler 
name for degenerate references to 'gcc -mno-cygwin'.

Re: Fixing mingw support in Python's distutils

Earnie Boyd — 2013-05-24T18:38:48

I don't think you should trust the results of -mno-cygwin, my guess is
eventually it will be dropped even in giving the deprecated warning.
I better method will be to test for the __CYGWIN__ predefined macro in
GCC.

is_mingw=`gcc -E -dM nul.c 2>&1 | grep -q __MINGW32__; echo $?`

That should be enough.  The value of is_mingw will be 0 if it is or 1
if not or there were some other error.

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-24T17:27:27

On May 23, 2013 8:41 PM, "Keith Marshall" <
keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org> wrote:
not.

I'm not trying to determine if gcc will accept -mno-cygwin. The problem is
that Cygwin gcc without -mno-cygwin will do the wrong thing (create a
binary that depends on cygwin.dll) or display confusing compilation errors.
I want it to just give the appropriate 'stop using -mno-cygwin' error
message so I intend to continue passing -mno-cygwin if it is a cygwin gcc.

I'm also not trying to develop a cross-compiler solution. I should be clear
about the cause of this problem. When someone installs Python, distutils is
installed with it. Distutils provides code to compile extension packages
using the compilers available on the user's system. Users can supply config
files or command line options to select the compiler that distutils will
use. So when a user supplies --compiler=mingw32 disutils assumes that mingw
gcc is on PATH and starts issuing commands to gcc.

At some point it was decided tha

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-24T16:40:48

On May 23, 2013 8:24 PM, "Keith Marshall" <
keithmarshall-Rn4VEauK+AKRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org> wrote:

Thanks, that does seem appropriate. If distutils were being redesigned it
might be better to do that.

However I don't think that distutils has ever previously assumed that
config.guess exists on the user's system so I don't think I can make that
change in a bugfix release. I doubt that it could go into a new release
either as distutils is "frozen" in general.

Thanks,
Oscar
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5ui

Re: Fixing mingw support in Python's distutils

Oscar Benjamin — 2013-05-24T16:34:00

http://bugs.python.org/file29032/0001-MINGW-issue12641-check-if-cygwin-mingw-compiler-supp.patch

Hi Roumen, I have reviewed your patch as requested by Martin and as I
already said on the issue tracker I would not accept it (not that it's
actually up to me). Please keep that kind of discussion on the tracker
rather than here.

not.

I'm not trying to test whether -mno-cygwin is accepted/supported. I'm
trying to test if *not* passing -mno-cygwin will result in a binary that
depends on cygwin.dll. If it will (because it's a Cygwin gcc) I will always
pass -mno-cygwin so that gcc can either build or show the appropriate error
message.

Oscar
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life

Re: Running a msys script from a Windows prompt

Paul Moore — 2013-05-24T14:08:39


Ah, OK. I was using standard backslashes - I hadn't realised that I could
use / and not bother about converting drive letters to /c/.



Cool, that's similar to what I'm doing, then, but including --login and
undoing the unwanted directory change afterwards. Sounds like it's about as
good as I can expect, then.

Paul
------------------------------------------------------------------------------
Try New Relic Now & We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app, & servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may_______________________________________________
MinGW-users mailing list
MinGW-users-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f< at >public.gmane.org

This list observes the Etiquette found at 
http://www.mingw.org/Mailing_Lists.
We ask that you be polite and do the same.  Disregard for the list

Re: Running a msys script from a Windows prompt

LRN — 2013-05-24T13:48:17

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 24.05.2013 17:32, Paul Moore wrote:
MSys understands DOSish paths just fine - as long as you use '/' as the
directory separator (so, do path_variable.replace ('\\', '/') and you're
good).

I do this:

argv = os.environ['BUILDSLAVE_SHELL'].split()
# Create a temporary script file that changes current directory
# and runs the command we want
tf, tf_name = tempfile.mkstemp ()
f = os.fdopen (tf, 'wb')
fcontents = '#!/bin/sh\ncd {}\n{}'.format (
    re.sub(r'(?<!\\) ','\\ ', workdir.replace('\\','/')),
    ' '.join (command))
f.write (fcontents)
f.close ()
argv += [tf_name.replace('\\','/')]

p = subprocess.Popen (argv)

and once it finishes:

try:
  os.remove (tf_name)
except:
  pass


(BUILDSLAVE_SHELL is set to "c:\....\msys\bin\sh.exe --login -c")
("command" is the command you want to run, as a list)
("workdir" is the directory to run the command in)

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (MingW32)

iQEcBAEBAgAGBQJRn2+gAAoJEOs4Jb6SI2CwsgQIALEWT3

Running a msys script from a Windows prompt

Paul Moore — 2013-05-24T13:32:00

I want to write a Python script in Windows that fires off a shell script to
run under msys. A simple test case is easy - I just use Python's subprocess
module to run

C:\Msys\bin\sh C:\MyScripts\script.sh

However, this does not seem to set up the msys shell environment correctly
- gcc is not in the PATH. I can't use --login, as that changes directory to
my msys home directory and I want the script to run in my current directory
under Windows. The problem is basically that the msys /etc/profile does
some essential things (setting PATH) but also some unnecessary ones
(changing directory).

I can't easily just use --login and change directory in my script, as to do
that I'd need to convert the current directory name from Windows form to
msys form (there's no equivalent of cygpath under msys - is that right?)

The best solution I have been able to find so far is to edit my build
script to start with the lines

x=$(pwd)
. /etc/profile
cd $x

That's a bit ugly (as it requires changing my script in a way that isn'