← Back to team overview

kicad-developers team mailing list archive

Re: boost_root driven by https


Hey Dick,

Thanks for all your kind words! It always helps everyone to have
encouragement and appreciation. Thank-you for the Python-a-mingw-us work,
it's really essential for us on Windows; I'm sure it will build in favour
as word gets around about it. Soon I will be able to pimp wxPython-cmake a
bit more to the wxWidgets guys when a gtk build is available. There are
several builds available for it already. wxPython-cmake can also be built
with MSVC (MicroSoft Visual C) now too - so it can be used with the
official python distribution. I need to upload the release for MSVC though
as I only have MSVC 11 and the release should be built with MSVC 9 to link
against MSVCR90.dll, the same as the official Python distribution.

I'm currently out of the UK, I'm on Phoenix, AZ. But I'll be back next

I'd also like to do a debug build of Python-a-mingw-us which works with the
debug version of wxPython-cmake which in turn can be used with Windows
scripting debug builds. At the moment this is broken because the python
headers modify/exclude and add various things when DEBUG is defined or not.
So a complete debug build would be the most sane way forward too.

Also I noticed that the scripting console is no longer displayed in PCBNEW,
it appears to always be hidden on Windows - so it's another thing that
needs sorting out. Hopefully it's just a minor glitch. I tested the
complete AUI sample in wxPython before I came out to the US and everything
appeared to work fine.

I can tag the OpenSSL DLL work into that. So I can get round to it soon...

Best Regards,


On 23 August 2013 06:54, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> http://www.linuxfromscratch.org/blfs/view/svn/postlfs/openssl.html
> Newer source might be available..
> Maybe they fixed a build script bug.  The instructions at the link include
> a couple of patches, one sounds similar to mine.
> There is hope.  It might be only a fifteen minute problem now.
>  On Aug 22, 2013 8:39 PM, "Dick Hollenbeck" <dick@xxxxxxxxxxx> wrote:
>> On Aug 22, 2013 7:43 PM, "Brian Sidebotham" <brian.sidebotham@xxxxxxxxx>
>> wrote:
>> >
>> >
>> >
>> >
>> > On 20 August 2013 17:39, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
>> >>
>> >>
>> >> KiCad Developers:
>> >>
>> >> Anyway I've looked, building some compiled libraries for boost is
>> required and I have
>> >> augmented CMakeModules/download_boost.cmake to conditionally build
>> some compiled boost
>> >> libraries, although that support is not enabled yet.  There is an
>> alternate execution path
>> >> in that module that does what it did before except for a new header
>> file location.
>> >>
>> >>
>> >> I have the boost build scripts mostly done, but want to take a break
>> so I am committing
>> >> what I have done so far.
>> >>
>> >> The net effect of this upcoming commit, short term, is that the boost
>> headers are moved into
>> >>
>> >> to
>> >>      <kicad_src>/boost_root/include/boost
>> >>
>> >> from
>> >>      <kicad_src>include/boost
>> >>
>> >> .
>> >>
>> >>
>> >> This immediately paves the way for a sensible
>> <kicad_src>/boost_root/libs/* as needed and
>> >> as used in the alternate execution path in download_boost.cmake.
>> >>
>> >> It also smoked out some bugs in our build scripts which were using a
>> bogus
>> >> Boost_INCLUDE_DIR variable, which was dis-functional, but now is
>> functional.
>> >>
>> >> If you have any problems with it let me know.
>> >>
>> >> (Thinking of ramifications across 3 platforms has taken its toll.  I
>> can however see a
>> >> clear path forward, and will be back at this within a week or two
>> after I recharge my
>> >> batteries.  My current thinking is to try and use boost::async and
>> forgo use of other
>> >> networking libraries on top of that.  On windows we will have to pick
>> up openssl support,
>> >> and that may mean insisting on the python install to pull it from
>> python a-mingw-us.  I
>> >> build it there, but not in DLL form yet.)
>> >>
>> > This sounds fine to me. I suggest we include a complete "install" of
>> python-a-mingw-us in the KiCad install anyway. It's the easiest way of
>> getting controlled Python support on Windows. It's how almost all of the
>> other open source efforts package their python scripting.
>> >
>> > Simply include the complete thing and KiCad can set PYTHONHOME to it's
>> root dir for it's sub-processes. This is how KiCad-Winbuilder arranges all
>> the executables and python-a-mingw-us works fine for KiCad scripting like
>> this.
>> >
>> > So it should only be pulling on resources that we'll already have
>> available anyway in that case.
>> >
>> Cool, agreement then.  I've spent 20 minutes twice, separated by 4 months
>> trying to get openssl to build as a DLL.  It was leading to unresolved
>> functions.  Will need more than 20 minutes to solve.  Brian if you are
>> feeling smart some day with some time, you could try and pull that off.
>> To trigger the attempt of course this is an edit to
>> pythonexternalprojects.cmake.  We should check for a newer src package.
>> After that hurdle, then the pyhon module has to be told about linking to
>> the DLL.  Then there is packaging the DLL, and telling windows how to find
>> it when running that python extension.
>> This is more than I can justify in time, since I don't even use windows
>> myself for 12 years.  The reward for having spent three and a half weekends
>> on a-mingw-us for my windows friends eludes me.
>> I know you have a comparable amount of time into the layers above that,
>> so I will say it in plain English because for some reason others seem to be
>> reluctant to use a person's name and thank you in the same sentence.
>> Brian, thank you for your truly exceptional and world class work in
>> bringing the software stack necessary for windows python scripting to
>> fruition. Thank you for believing in my vision, and in my a-mingw-us work,
>> and following my lead.  You were basically the only one.  Now it is your
>> effort and follow through that *I* salute.  In fact by the time we look at
>> what you've done in the installer, and in winbuilder, your work easily
>> surpasses mine.
>> I find you to be an invaluable member of this team.
>> > Best Regards,
>> >
>> > Brian.
>> >

Follow ups