On 9 April 2013 14:34, Dick Hollenbeck <[email protected]> wrote: > On 04/08/2013 04:21 PM, Brian Sidebotham wrote: > > Hi Dick, > > Sorry I've been away from the KiCad list and my keyboard for a bit - > but I was busy getting married. > > > Sounds like nothing that needs apologizing for, but rather celebration > for. I will drink a beer for you tonight. What a joyful time for you. > > Well, that's the very reason I've been away. We're off to the Maldive's in a few days and then it's back to the grind stone. Thanks for having a beer for us, it's appreciated!
> > > Now that married life is treating me well, I can re-focus on getting > the Windows scripting support complete. > > I've just committed a fix for the incorrect Window's API function > prototypes. > > > Thanks. This will also get propagated to python 3.4 if I can execute > my plan to port the cumulative body of work in python a-mingw-us to > the newer dev (aka 3.4) branch. > > > Those last couple of extensions I built, namely readline, and curses: > > > a) Were not tested by me. (Seems we should at least get readline > working for the shear user convenience of scroll recall.) > > I assume scroll recall is simply pressing the up arrow key to get previous lines? I didn't notice that this wasn't working, in fact I'm sure I specifically tested it and it did work. I'll have a look tonight. > > b) Requires wine-32 and wine-64 installed in order to satisfy a > "windows presuming" configure script in one of those external packages > (cannot remember which of readline or ncurses has the problem). > I have both wines installed so both 32 and 64 bit extensions build > here on ubuntu precise just fine. > > > Ideally a patch would be made to the configure script which wants to > run some *.exe, and that could be avoided like a good little cross > compilation configure script should. (This is typically done by > testing the "build" machine type and comparing it to the "host" type. > But that configure script is too stupid to do that.) Sometimes it is > easier just CMake-ifying the whole darn build system for an external > package. I've done this for packages as large as pppd, and it is > often worth the work. > > Urgh! Okay, I'll look into this issue and see if I can follow your lead with either a patch or a replacement cmake build system for the culprit. > c) you may have to add some cmake install() commands to get what is > needed out of the windows ncurses package data, "terminal data". We > can switch to pdcurses if this becomes a pain. After all, this is a > windows targeted effort. > > > I'll look at building ncurses as above and we'll see what problems rear their ugly heads. > Since you are maintaining winbuilder, it becomes possible for you to > download pre-built binaries for library and python portions of the > kicad build. I am thinking the *.zip file packaging we have for > a-mingw-us is perfect for you and winbuilder. > > I would like to have a more visible location to host python > a-mingw-us, offering: > > a) 32 & 64 bit prebuilt binaries (which winbuilder can download). > > b) the source tree, now in bzr, converted to whatever. > > c) options for community building. > > > I am leaning towards google code at this point, since it is possible > to have the wiki and discussion areas. I do not like git. (And > github limits the width of visible lines on its website, even after I > posted a RFE more than a year ago about this. It is alarming what > $100,000,000 in venture funding cannot do.) > > Yep, that sounds good. Launchpad is awkward to download zip releases from in cmake. So any service that can provide a permanent URL for downloading the release is welcome so long as they can provide the code hosting facilities too. > If any of this is something you would enjoy doing, I would certainly > appreciate any help I can get. Obviously the goal would be for > a-mingw-us to be taken over by its own community as a minimum, and > best case is it all gets merged into 3.4 python tree. > > I'll look at sorting out the wine dependency as that sounds like the worst case problem at the moment. I'll let you know how I get on > > Remember, none of this was for me. I don't use windows, period. All > this work was for KiCad windows users and developers. (Python works > now on linux, just fine, eh?) > > So my preference is for getting windows users to take this over if > possible. The difficult aspect of that is that windows users tend to > be windows developers. And python a-mingw-us is a cross compilation > environment from linux. > > That narrows the potential list of helpers significantly, well maybe > down to you Brian and a small band of your assistants. :) > > Yep, I understand. It is difficult. Thank-you for all your effort so far, you've put a tremendous amount of work into this project already! I see this as a nice stepping stone for those people anyway. Building this project in Linux is a joy - it basically just builds with no issues. Now that the standard response can simply be to tell someone on Windows to setup a VM with Ubuntu or something on to build the project means that more of those Windows developers should migrate to Linux. Best Regards, Brian.
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
