← Back to team overview

kicad-developers team mailing list archive

Re: Python scripting cmake build macros.


On 30 January 2013 19:14, Wayne Stambaugh <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

Best Regards, Brian.

Follow ups