kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 01/25/2013 04:08 PM, Brian Sidebotham wrote:
> I think this is worthy of another new thread, but is a fork of the Python Scripting
> cmake build macros. There are some notes on using MinGW with msvcr90.dll as a target C
> runtime.
>
> I added a new specs file to my local KiCad MinGW install (see attached). This goes in
> the <mingw-root>\lib\gcc\${VERSION}\ folder.
>
> Then we need to compile using that specs file. Just use -specs=specs90 as a compiler
> option. The default specs file for gcc is called specs. So if you want the compiler to
> default to build for msvcr90 you can rename the attached file to specs and you will not
> have to use the -specs= compiler option.
>
> The next problem is with msvcr80 onwards where executables require a manifest. The
> executable will not run unless it has a manifest. Normally the compiler embeds the
> manifest in the executable, but in MinGW's case that doesn't yet happen, so you need a
> manifest file like the one attached, named the same as the executable and suffixed with
> the extension .manifest. For example for the executable test.exe you need to supply
> something like the XML attached in a file called test.exe.manifest alongside the executable.
>
> There is some information about the manifest
> here: http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191(v=vs.85).aspx
> <http://msdn.microsoft.com/en-us/library/windows/desktop/aa374191%28v=vs.85%29.aspx>
>
> Python 2.7 using msvcr90 as the runtime library. You can get the re-distributable
> package from the following location if your system is missing
> it: http://www.microsoft.com/en-us/download/details.aspx?id=5582 
>
> I believe that the manifest issue can be solved by compiling the latest MinGW Runtime
> with a series of patches which will include the manifest.
>
> Some information about patching and compiling the latest MinGW runtime can be found here
> along with more information about these
> issues: http://developer.berlios.de/devlog/akruis/2012/06/10/msvcr90dll-and-mingw/
>
> All this will move us towards a toolchain that should be able to use the pre-compiled
> python and wxpython distributions for Windows.
>
> Dependancy Walker shows this mod to be working correctly. If you get an error with a
> test program saying that the C runtime library has been started incorrectly it's likely
> there's a problem with the manifest file.
>
> Lastly, apparently GPL V3 has removed the problem with distributing the msvcr90.dll (or
> whatever version).
>
> Best Regards, Brian.


Thanks Brian.

Your expertise in the realm of the various Microsof CRT libraries exceeds mine.  Some of
this gets more political than technical as far as I am concerned, and I will never get
into that MS political stew again.  You know, like the "Windows 8 computer", which has a
hard time booting Linux because Microsoft tricked hardware OEMs into embracing something
that would lead to a Microsoft tax.  My next computer will not have such a bios.


So I will be relying on others, ( you, Wayne, Miguel, ??.. ) to carry this into daylight.

I have done the heavy lifting, the patch is 3.5 megabytes in size.

But I am willing to toss the entire thing in the trash before I get involved in kissing
Microsoft's ass again.  That means the groveling at the CRT level will have to be done by
someone else.



About the CMake/Mingw/Python Support:
====================================

This 2.7.4 CMake build environment is only expected to be used to generate binaries.  That
is an important concept to understand, because it keeps you from thinking it is a
development environment.  This patch will not get accepted into the python tree at the
2.7.x branch.  Not until it gets ported to 3.4 will it have a chance of being accepted,
python team policy.  So we can think of having two patches, one for "2.7.4...." and one
for "dev=3.4" branch.  The 2.7.4 patch is where we can learn, and solve our immediate
need.  The "dev" branch patch is important to get accepted because it would remove us from
any maintenance burden moving forward.  Somebody will have to be-friend the python
developers and dribble the thing in piece by piece, I could get that started at some
point, but would prefer someone else to eventually take ownership of it.  If we have a lot
of python customers using the 2.7.4 support with a shiny installer, that will help in
creating appeal.

So I don't want to hear that these 2.7.4 patches won't let you build on platform XYZ.  As
I deliver it, it will work on x86_64 Ubuntu Precise, that is all.  I suggest you might
want to install Virtual Box on Windows64, then install Ubuntu Precise in there.  Or use
two computers.  This way you can build the python 2.7.4 Mingw{x86_32,x86_64} platforms in
the VM, and run it immediately on Windows.  Or you could use a second computer.

For the dev=3.4 patch, I will create a copy of this one, and it will evolve from there. 
That one needs to be more polished. 

But the problem of course is this:  a lot of these ExternalProjects use
autotools/configure, and that won't run on Windows.  So the subprojects, which are now
about 65% of the build, they cannot even be done on Windows in a way that I could
tolerate.  (And this is of course why all projects that use autotools are not particularly
concerned with the Windows developer.)

Each ExternalProject could be patched with a CMake build environment, then it could all
happen on Windows.

I will send you some binaries in the next few days.  And the work will be in a bzr
branch.  In that branch, "Revision 1" equals pristine python 2.7.4.  To generate the patch
you just do a diff from rev 1 using bzr.

For the wxWindows stuff, I have cross-compiled those in the past using Linux to Windows. 
CMake might only be used to generate installers from the result.  A single
ExternProject_Add() would wrap the existing build mechanism, and then do the packaging
after that.

Same for wxPython.

Dick