kicad-developers team mailing list archive

[Wayne Stambaugh <stambaughw@xxxxxxxxxxx>]

On 1/31/2013 9: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.
> 
> However, I've also read that the MinGW Runtime 4.0 is some way off yet.
> For example, the testing framework sounds like it's going to take some
> time all by itself:
> http://www.mingw.org/wiki/WSL_Testing_Infrastructure_Development
> 
> I will continue down this path for a bit longer and pingback any useful
> information to the list. I'll be very interested in hearing about the
> python-mingw win32 method too.
> 
> Hopefully we can come up with a maintainable way forward without "too"
> much pain.

Haven't we already crossed this threshold? :)

> 
> Best Regards, Brian.
>