kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 09/29/2013 05:43 PM, Brian Sidebotham wrote:
> On 26 September 2013 15:07, Dick Hollenbeck <dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>
> wrote:
> 
>     On 09/26/2013 04:51 AM, Brian Sidebotham wrote:
>     > On 22 September 2013 05:37, Dick Hollenbeck <dick@xxxxxxxxxxx
>     <mailto:dick@xxxxxxxxxxx> <mailto:dick@xxxxxxxxxxx <mailto:dick@xxxxxxxxxxx>>>
>     > 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.