kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/31/2013 08:50 AM, Brian Sidebotham wrote:
>
> On 30 January 2013 19:14, Wayne Stambaugh <stambaughw@xxxxxxxxxxx
> <mailto:stambaughw@xxxxxxxxxxx>> wrote:
>
>     On 1/30/2013 4:33 AM, Brian Sidebotham wrote:
>     > Hi Wayne,
>     >
>     > You're right - it's not exactly straight forward, there are problems to
>     > solve.
>     >
>     > I got the specs file to work correctly with the variable substitution,
>     > perhaps you could try the spec90 file I attached to another mail on the
>     > list? I'm using the latest MinGW version - 4.7.2 too.
>     >
>     > I wonder if you have a link library ordering issue as write should
>     > definitely be linked from any C runtime.
>     >
>     > I am getting some other issues, relating to "time" which I think went
>     > under "breaking changes" as Microsoft seem to word it during the VS2005
>     > (msvcr80) change.
>     >
>     > In the link to Anselm's
>     > notes: http://developer.berlios.de/devlog/akruis/2012/06/10/msvcr90dll-and-mingw/ it's
>     > worth looking at the section about the MinGW Runtime. There is some
>
>     Gee, is this all we have to do.;)  It looks like either approach we take
>     (CMake for Python or get MinGW to play nice with msvcrxx), will require
>     a significant effort on our part.
>
>     > patching required to get around the differences between the old CRT and
>     > the newer CRTs where Microsoft decided to just delete functions and
>     > types! This breaks the glue.
>     >
>     > I haven't yet got around to patching the MinGW Runtime and trying
>     > compilation with that, hopefully I will at the weekend, but time is very
>     > tight at the moment.
>     >
>     > We are a bit ahead of the curve on this really. But at least the MinGW
>     > guys are gradually adding this support into MinGW.
>
>     I'm a bit reluctant to use unreleased stuff from MinGW.  It could change
>     significantly between now and the time it's released which means we
>     would have to keep things well maintained.  The CMake solution seems
>     like it would have a better chance of success no matter which direction
>     MinGW goes.
>
>     Thanks again for digging up this information.  It certainly was
>     enlightening.
>
>
> Hi Wayne,
>
> No problem at all. I'm not ready to give up on it yet, and it'll probably be best if we
> explore all of the possible ways forward. I don't like the chances of compiling the
> pywin32 python package with MinGW.


What is pywin32 exactly?  The sourceforge website for it says nothing.  Is this simply
python for windows, carried to you in an installer?