kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

On 31/01/2013, at 16:45, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> 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?

It's a module/library inside python standard stack, which is used (abstracted, of course)
to provide OS related functionality.

Wayne & Brian, thanks a lot for the hard work on this thread you've been doing lately, I'm
reading all your efforts, but contributing nothing, big changes at projects lately (for good),
but I'm needing more than expected to adapt… 

Please let me know if you want to have some rest on the task at any moment, I promise to find
the time for it.