On 30 September 2013 00:13, Dick Hollenbeck <[email protected]> wrote:
> 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 > > 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.
_______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
