kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 7 October 2013 05:56, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> On 10/06/2013 06:05 PM, Brian Sidebotham wrote:
> >     > On Windows, building without the msys environment means perl is an
> absolute no-go
> >     area for
> >     > me;
> >
> >     Android cell phone found this this morning, while I was laying in
> bed.  I guess it wanted
> >     to be relevant, helpful, and to cmake a difference:
> >
> >
> >     https://github.com/LuaDist/openssl
> >
> >
> >
> > Hi Dick,
> >
> > Thanks for this link. KiCad-Winbuilder just puts the 1.0.0d release of
> the luadist openssl
> > project in it's environment and points the OPENSSL_ROOT_DIR variable to
> the install. This
> > works well - so there's no need for me to create a separate project. The
> Luadist openssl
> > binary release is compiled to rely only on msvcrt, so there are no
> C-Runtime library
> > conflicts.
> >
> > We could easily use this project through ExternalProject_Add to if we
> preferred that approach.
> >
> > Best Regards,
> >
> > Brian.
> >
>
> The audience most likely to be dissappointed with the current setup is a
> KiCad Windows
> builder person that is not using KiCad-Winbuilder.  I am not in that
> audience, so I am not
> the best spokesperson for their pain.
>
> The only pain I'd have to suffer is if you were thinking of bringing in
> all the source for
> that lua openssl project into KiCad and adding it to our tree.  I'd prefer
> not to do that.
>
> There are quite a number of alternatives all of which would use
> ExternalProject_Add().
>
> Someday in the next year or so we could rely on the new CMake 2.8.11
> support of https://
> downloads.  That would get you the most recent zip file from github, but
> it would not pin
> the version number.  Each download would be today's version.
>
> Alternatively, you could strip out all the CMake scripts into a patch and
> apply that patch
> into a pristine (older?) openssl download using ExternaProject_Add().
>  Having that patch
> in our tree (dir: /patches) would not bother me at all.
>
>
Hi Dick,

This alternative would be my favourite choice. I think we can just extract
the CMake scripts, tidy them a bit because they use the old style CMake
install commands, and also remove the Luadist specific stuff and we should
be able to easily patch them on top of a vanilla OpenSSL source.

The OpenSSL source is very stable, I think the only changes they make are
to close buffer overflow and other security risks, so the source code file
set remains predominately unchanged between releases.

I'm more than willing to do this and it would be more in keeping with our
CMake build system.

Then, we could submit it to openssl folks and ask them (no doubt "again")
> to offer a
> sensible build system for poor Windows builders.  You would think the lua
> guy that did all
> that work did that, but who knows.  Piling on seems appropriate in any
> case.
>
> The only thing I've been afraid of is to push Windows builders into using
> patch.exe.  You
> scared me away from that.  So we went with "bzr patch", but that only
> works in a bzr
> working tree.  So I've had to check in anything needing to be patched into
> a scratch repo,
> just to establish a working tree.
>
> LOL, why is patch.exe not included as part of Windows?
>
> Thank goodness we have you Brian to sort this all out.
>

I agree, Windows is lacking a lot.

It's a shame bzr patch requires a working tree. That is a pain. The
original problems with patch.exe were coming from the Windows User Access
Control layer which prevents access to any executable called patch.exe!
However, it can be circumvented by having a manifest file alongside the
executable which reassures Windows. So just something to trip the normal
user up with no enhancement what-so-ever!

Thank goodness for projects like CMake, mingw-w64 and the like!! That's the
only way any of these builds are possible.

Plus of course, thanks to you and everyone else for building everything so
solid on top of CMake so that just a bit of tweaking is needed to get
things building on Windows!

Best Regards,

Brian.