kicad-developers team mailing list archive
Mailing list archive
Re: boost_root driven by https
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
> 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
> 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
> 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.