kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 1/17/2013 10:58 AM, Dick Hollenbeck wrote:
> 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).

I will help out where I can.  Once Miguel has a source repo up and
running, I will check out the code and give it spin.  If we can cross
compile on Linux, we should be able to get it to build on MinGW on
Windows as well.  We know we can get wxWidgets to build on MinGW so that
only leaves wxPython.  Thank you Miguel for your efforts.

> 
> 
> 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.

I find it difficult to understand why the Python folks would not want a
larger target audience.  The CMake stuff could be merged in parallel
without interfering with any of their current build system.  I just
don't see any downside to this solution.

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

Them along with the wxWidgets folks.  The release announcement on the
wxWidgets site states that 2.9.4 is stable enough for production use.
If that is the case, why not bump the revision to 3.0 and call it
stable?  Maybe they are trying to beat Emacs record of 7 years between
stable version releases.