On 1/31/2013 9:50 AM, Brian Sidebotham wrote: > > On 30 January 2013 19:14, Wayne Stambaugh <[email protected] > <mailto:[email protected]>> 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. > _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
