kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 10/07/2013 04:56 AM, Brian Sidebotham wrote:
> On 7 October 2013 05:56, Dick Hollenbeck <dick@xxxxxxxxxxx <mailto: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. 


Mine too.  I provides the best record of what changes are being made, and it provides the
summary of the upstream argument.  Then if the upstream argument is won, the patch goes
away.  This how the openemebedded system works, debian, etc.

This path might be helpful for the OSX folks too or for someone on linux also, although
linux is unlikely.



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