kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/17/2013 09:25 AM, Miguel Angel Ajo Pelayo wrote:
>
>
>
> 2013/1/17 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
>
>     On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote:
>     >
>     >
>     >
>     > 2013/1/17 Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>
>     <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>>
>     >
>     >     Nice job, I am glad I was able to inspire you to see the light.
>     >
>     >
>     > Just did nothing but follow the readme, it's good that you found it. I hope I will be
>     > able to port it to the latest 2.7.x python, anyway, I will consider that low priority,
>     > it's not a stopper at all.
>     >
>     >
>     >
>     >     This approach puts the task firmly in your comfort zone.
>     >
>     >
>     > Mine, and everybody's I hope, the python build scripts are a mess :-)
>     >
>     >
>     >     It would not be unreasonable for you to be a maintainer of your very own
>     >     Mingw-Python for
>     >     Windows binaries, you know, like a rock star, I mean package maintainer.
>     >
>     >
>     > I forked the cmake script so in the case we do some enhancements I will send them back
>     > for merge.
>
>     ??
>
>     Was thinking you would maintain a full hg python tree, with the CMake stuff in there all
>     the time.
>     This way you can pull from upstream, and generate a diff which constitutes the CMake
>     patch
>     at any time.
>
>     The form of David's work now is actually pretty inconvenient to use, since:
>
>     a) it is not actually a patch but rather an overlay.
>     b) he makes the mingw stuff optional, and it should not be.
>
>     In your shoes I would maintain a full separate python tree in hg, say perhaps on google
>     code if they support hg.
>
>
>
> Another DVCS system? (waaahhhh)... ';-)
>
> Will give it a try when we have something that can go upstream for 3.x
>  
>
>     >
>     >
>     >
>     >     Remember that python has to compile with gcc for linux, so the python source
>     is always
>     >     going to be mostly acceptable for mingw-gcc.
>     >     You only have to worry about the boundaries such as system calls and library
>     functions.
>     >
>     >     It does not seem overly difficult to maintain a big ass patch indefinitely if
>     the python
>     >     guys prove too stubborn for your CMake preferences.
>     >
>     >
>     > Well, the 2.7.x branch must be maintaned only for security and bugs, but no new
>     > features, so it should be not a problem.
>
>     It will be a larger problem getting the patch accepted here than in 3.x, according to
>     python mailing list postings I've read.
>
>     Your 3.x work is important now in my opinion.  Feel free to build a team of helpers.
>
>
>
>     >
>     >
>     >     You could have a separate patch for 3.x python as well, and compete with them on
>     >     superior
>     >     packaging until they see the light.  Use CMake packaging to keep it simple and
>     fast.
>     >
>     >
>     > Hehe, 3.x is another war, that we must fight later :-), but we must keep that in mind
>     > and write 2.7 - 3.x compatible code.
>
>
>     I do not agree.  The 3.x patch will be easier for the python developers to accept,
>     according to mailing list postings.
>
>
> Yes, but 3.x yet feels like bleeding edge for me (wx python with 3.x still not available 
> by default in most linux distros as Wayne investigated).


Good point.  But when you hand somebody a cross platform build infrastructure on a silver
platter, it sort of removes a lot of excuses for not offering it in the next distro.

python 3.x is not bleeding edge.  wxpython project needs a kick in the ass, and needs to
get off its ass.