Ray Donnelly added the comment:

Re: basing the patches against the latest master branch or targeting released 
versions, I wasn't clear enough about my thinking.

For sure, when trying to get any patches merged, the submitted patch must be 
re-based (forward ported) and tested against the master branch. 

But from the perspective of having a project that people can reliably expect to 
build a working MinGW-w64 Python from (until that elusive fully-merged-day 
comes), having patches based on the latest released versions seems to me to be 
the best thing to do (for that goal of course)

I'll keep forward porting these patches to each new release, and at those times 
I'll also submit some of them as issues to bugs.python.org as that's the best 
way for me to manage my limited spare time.

Do you know what the situation is with packaging/distutils2? I think our next 
good merge opportunity for the bulk of these patches will be when we can target 
that instead of distutils.

> Maybe you could even separate the patches into a patch supporting a native 
> mingw build and a cmingw ross build?

I'm already doing that:
https://github.com/mingwandroid/crucifixion-freedom/tree/master/patches/python/3.3.0

0000 and 0005 are now merged with upstream. 0000 you merged today, 0005 was 
merged also (mostly via Roumen's patches which 2/3 of my patch duplicated). At 
this stage, the framework for cross compiling Python is mostly merged; other 
than 0065-cross-dont-add-multiarch-paths-if-cross-compiling.patch

The stumbling block for me is that there's no working example of 
cross-compilation in CPython so it will surely rot. This was what I tried to 
fix with my next patch, 0010-cross-darwin-feature.patch. I went for darwin 
instead of MinGW as the amount of changes needed is tiny but it was met with 
some resistance and hasn't seen any activity for 3 months:

http://bugs.python.org/issue16291

I should also clarify, by cross compilation I'm specifically excluding 
GNU-Linux/GNU-Linux combinations such as x86-GNU-Linux/arm-GNU-Linux as they're 
not as exhaustive a test-case as cross-compiling between different OSes.

> Maybe you could even separate the patches into a patch supporting a native 
> mingw build and a cmingw ross build?

Not sure if that was directed at me as my set of patches are logically split up 
I think. Ones with 'mingw' in the name relate to mingw (either cross or 
native), ones with 'msys' in the name relate to building mingw natively and 
ones with 'cross' in the name relate to general cross compilation matters; ones 
with 'hack' in the name generally need improving, rewriting or removing.

----------

_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue3871>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe: 
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com

Reply via email to