kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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