kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 04/09/2013 11:59 AM, Brian Sidebotham wrote:
> On 9 April 2013 14:34, Dick Hollenbeck <dick@xxxxxxxxxxx
> <mailto: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?

yes

> 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.


I do a scratch dir under /tmp/ for making the patches.  CMake's
External_Project_Add() supports one patch "command" per external
project.   Technically I think
this can be a multiple patch program invocations using the &&
operator.  Something like:

PATCH_COMMAND patch -p0 <
${CMAKE_CURRENT_SOURCE_DIR}/cmake/openssl-1.0.1c.patch
  && patch yet more
  && patch yet still more

However, using bzr you can use it to generate patches quickly:

*) after untarring the download into /tmp/* then do
*) bzr init .
*) bzr ci -m initial

Then do your changes, at the end simply do

*) bzr diff > feedthistocmake.patch


So a single patch is probably easiest.



>
>
>     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.


You da man!

Your willingness to help is taking a load off my mind.


I will look into google code.  Another draw there is their support of
hg, which is what the python team is using.  This might lower the
barrier to pulling stuff out.  But I will not forget your concern
about a permanent URL or FTP or HTTP for the cmake *.zip downloads.


Dick