On 09/29/2013 05:43 PM, Brian Sidebotham wrote:
> On 26 September 2013 15:07, Dick Hollenbeck <[email protected] 
> <mailto:[email protected]>>
> wrote:
> 
>     On 09/26/2013 04:51 AM, Brian Sidebotham wrote:
>     > On 22 September 2013 05:37, Dick Hollenbeck <[email protected]
>     <mailto:[email protected]> <mailto:[email protected] 
> <mailto:[email protected]>>>
>     > wrote:
>     >
>     >     On 09/21/2013 09:23 PM, Dick Hollenbeck wrote:
>     >     > I will fix it if it does not work on linux....
>     >
>     >
>     >     Did that, it works now, and brilliantly.
>     >
>     >
>     >     We had a namespace collision on FPL_CACHE, my destructor was going 
> into
>     LEGACY_PLUGIN's
>     >     FPL_CACHE destructor.  Linker did not catch that, because geez, it 
> was thinking
>     it was the
>     >     same class.   Have given each FPL_CACHE class a unique name, could 
> have used a
>     namespace
>     >     but did not.
>     >
>     >
>     >     Then, I removed PCAD from FP_LIB_TABLE dialog, which does not 
> support Footprint*()
>     >     functions.  *In its place I added "Github" plugin.*   This was me 
> pulling the
>     trigger.
>     >
>     >
>     >     It works now.  And it is really exciting.
>     >
>     >
>     >     *I am all for getting our stock footprints on github ASAP!*
>     >
>     >     Whoever is in charge of those now, please lets rock the footprints!
>     >
>     >     Please talk to your platform sponsor about getting the PLUGIN to 
> run on the
>     Windows and
>     >     OSX platforms.  I don't have those, and will not be helping more 
> than I have.  I
>     wrote
>     >     CMakeModules/download_openssl.cmake and it might work with minor 
> edits if you
>     have perl on
>     >     your windows system because the damn openssl Configure program uses 
> perl.
>      Otherwise if
>     >     you have access to precompiled openssl libs and headers another 
> way, you can
>     force the
>     >     issue at or around line 31 of pcbnew/github/CMakeLists.txt by 
> defining
>     >     OPENSSL_INCLUDE_DIR and OPENSSL_LIBRARIES cmake symbols.
>     >
>     >     Sort of like this:
>     >
>     >     set( OPENSSL_INCLUDE_DIR
>     >         ${PREFIX}/include
>     >         CACHE FILEPATH "OPENSSL include directory"
>     >         )
>     >
>     >     set( OPENSSL_LIBRARIES
>     >         ${PREFIX}/lib/libssl.a
>     >         ${PREFIX}/lib/libcrypto.a
>     >         CACHE STRING "OPENSSL libraries"
>     >         )
>     >
>     >
>     > 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


This above project wrote a CMakeLists.txt tree for openssl.  It could be a 
lower hurdle
for someone determined to build openssl on windows, since it does not require 
perl to
build openssl, presumably only CMake.

Boost on Windows per Brians findings below, I guess.



> 
> 
> 
> I am building OpenSSL on Linux using mingw-w64. I swapped Winbuilder over to 
> mingw-w64
> sjlj. Everything builds and works correctly now. I'll create a patch in the 
> next few days
> once I've tested a bit more.
> 
> Boost wasn't building correctly (well actually, as I mentioned on Stack 
> Overflow - it
> doesn't install correctly) with the original mingw toolchain. However, it 
> does with
> mingw-w64. So that ended up being a good move anyway to satisfy the boost 
> build step.
> 
> The first thing I got was an IO_ERROR exception from PCBNEW because the kicad 
> folder
> didn't exist for the fp-lib-table. Once I created the folder the fp-lib-table 
> file was
> created along with a message telling me it had been created.
> 
> Application startup-time is massively improved after moving to the mingw-w64 
> toolchain
> too. I guess the dwarf-2 unwind tables take a while to setup, sjlj doesn't 
> have to create
> them. However, that is merely a reasonable guess. I suggest that anyone using 
> mingw moves
> to mingw-w64 as soon as possible. I think the old mingw project is loosing 
> traction quickly.

Any problems getting GITHUB_PLUGIN to build?  To run?  Did you need to 
separately install
the OPENSSL root certificates?

Thanks for reporting your findings and your hard work.

Dick


> 
> Best Regards,
> 
> Brian.


_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to     : [email protected]
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Reply via email to