kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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