kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

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

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,

Brian.


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