kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 4 February 2013 14:26, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

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

Thank-you for the information Dick.

I use several Ubuntu and Debian VM's on my Win64 PC, so no problem.

I wonder why I bother running things on the Windows OS really, I mean a
Linux VM that's given 4Gb RAM and 4 cores certainly rips along on my PC so
really native linux apps are not a problem to run.

I see open source being able to take the decision not to bother running on
all OS's natively very soon. I mean I could easily run KiCad on a Linux VM.
Why cant VirtualBox just be a pre-requisite of running the software?
Perhaps I'm just where you were years ago!?

I'm certainly not interested in anything autotools, especially on Windows.
I've read books on autotools and done projects with autotools, and I hated
every minute of it. I really like CMake, it's such a massive improvement.

I can do any testing you need doing on Windows, just shout. Thanks again
for all your efforts, they are appreciated by many people!

Best Regards, Brian.