kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

Brian,


On 03/18/2013 11:40 AM, Brian Sidebotham wrote:
> Excellent work Dick!
>
> I'll commit the changes for the incorrect windows API declarations
> and use which results in the incorrect warning message about python
> not being able to get the current activation context.


yes, please do.


I added support for readline.pyd today.  (This was the motivator for
ncurses.)


Now you get your fancy up arrow while editing from the python command
prompt.  Note that the MSVC build does not support that feature, so we
are now one ahead.



Tried to get the alternative libedit to work too, but "configure" got
in the way, again.  Thought about CMake-ifying libedit, then ran out
of time, threw in the towel.

(Somebody should setup up a site like github.com and make a policy to
only accept projects which do not use autotools.  It really has come
to that.)


>
> I'll also push the patch to the python guys so that they can fix it
> upstream.


If you want, but this might be a waste of your time.  This is only one
of about 200 patches that deserve to go into python 2.7.4.  Well in
fact they did, they went into python a-mingw-us.  :)

As mentioned before, I was going to focus on 3.4 for that upstream
push battle.  If you want to test the waters now, or give them a heads
up as to what is coming, go ahead.

I'll watch and cheer as if you were a gladiator, and take notes.



Python a-mingw-us  2.7.4
========================

You have a nice means of generating {32,64} bit binaries, which are
packaged now into a zip file.
The zip is convenient for any super set (layered-on) packaging or
building environment.  (No kicad user wants to build python itself,
ergo binaries.)

You can switch over to this for kicad-winbuilder, and perhaps adopt
the same strategy for both wxWidgets and wxPython.
CMake can download and unzip a zip file just fine.


What's left for a-mingw-us 2.7.4 ?

Creating a buzz:
  *) for non KiCad users of Python a-mingw-us, we'll need to finish
the NSIS.

  *) we will need to have binaries for download and direct use in NSIS
form.

  *) we will need a more visible host site, one that uses the
a-mingw-us logo.

No coding is left as far as I can tell.  Everything for 2.7.4
a-mingw-us "to do" is not coding related.  That means anyone can do it.

* I am done coding on Python a-mingw-us 2.7.4 *



Python a-mingw-us  3.4  a.k.a "dev"
===================================

Migration from 2.7.4:

 *) create the big ass patch from 2.7.4.
    bzr diff -r1

 *) use filterdiff to split it up as needed.

 *) go through each file, see where it applies to dev.


If it is thought that this CMake engine is to be the holy grail for
building all of python on any platform for any platform, then broaden
and fix the support for other than

   Linux -> MingW

cross compiling, which is what is perfected now.

Pushing upstream:

 *) join python developer's mailing list

 *) crawl before we walk, walk before we run

 *) submit patches, starting with most palatable.