kicad-developers team mailing list archive
Mailing list archive
Re: boost_root driven by https
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...
On 23 August 2013 06:54, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:
> 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>
>> > 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
>> >> Boost_INCLUDE_DIR variable, which was dis-functional, but now is
>> >> 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
>> > 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.