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.
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.)
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.
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.
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.)
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.
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. :)
Dick
Best Regards, Brian.
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
