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 <[email protected] <mailto:[email protected]>> >>>> >>>> On 01/17/2013 08:56 AM, Miguel Angel Ajo Pelayo wrote: >>>> > >>>> > >>>> > >>>> > 2013/1/17 Dick Hollenbeck <[email protected] <mailto:[email protected]> >>>> <mailto:[email protected] <mailto:[email protected]>>> >>>> > >>>> > 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. > > > > > > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
