kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 9 April 2013 14:34, Dick Hollenbeck <dick@xxxxxxxxxxx> 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.