kicad-developers team mailing list archive

[Brian Sidebotham <brian.sidebotham@xxxxxxxxx>]

On 30 September 2013 00:13, Dick Hollenbeck <dick@xxxxxxxxxxx> wrote:

> 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
>
>
Hi Dick,

No problems getting GITHUB_PLUGIN to build. I've not connected it to a
github repository as I run out of time last night to generate a library.
I'll have a look at it tonight and see how things go.

I haven't installed any of the root certs for OpenSSL, but thanks for
pointing that out incase I stumble across that type of problem.

I'm sure I'll have some more information in the next day or so. The only
real issues were mingw, building openssl - the cmake effort you pointed at
did make the cmake implementation look very easy for the openssl build btw!
Then it was just boost library names which are not sym-linked on Windows,
so we end up with something like libboost-date_time-mgw48-mt-1_54.a for a
boost library name.

Best Regards,

Brian.