kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 1/17/2013 12:36 PM, Dick Hollenbeck wrote:
> On 01/17/2013 11:10 AM, Wayne Stambaugh wrote:
>> 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. 
> 
> Awesome Wayne, thanks. This is a big job.

I figured as much.  I'm just a gluten for punishment:).  Actually my
goal is more of technical/moral support role.  I hope that I can keep
code contributions to a minimum.  I want to stay focused on KiCad.
There still is much work there to be done.  That being said, I still
think its important to provide wxPython scripting for all of our users
not just our Linux users.

> 
> 
>>  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.
> 
> 
> With a CMake build infrastructure for the whole stack, and CMake install() support, CPack
> lets you spin out *.deb and *.rpm files also.
> 
> We can decide to lead, not follow.  The work done toward plugging the Windows hole, 6
> packages, results in freedom on other platforms as well, all due to CMake of course.
> 
> 
> 
> 
> 
>