Re: [Kicad-developers] OpenSSL-CMake build system

[Brian Sidebotham]

On 8 November 2013 16:42, Dick Hollenbeck  wrote:

> > I commented this out because CMake barfs if you pass
> CMAKE_TOOLCHAIN_FILE as a blank
> > value. I left it in, but commented out for exactly this sort of
> feedback. I've included it
> > in a conditional which checks to see if CMAKE_TOOLCHAIN_FILE is blank.
>
>
> Well done, perfect solution.
>
> one extra comment line we don't need now, due to your magic and amazing
> build system work
> on OPENSSL:
>
># this requires that perl be installed:
>
>
> Any luck getting this CMake work accepted upstream on any of your numerous
> upstream CMake
> efforts?
>
>
Oops, missed that comment. I've removed it now.

There hasn't been any luck in getting the CMake build systems integrated
into any of the projects yet, but to be fair I haven't really put in any
effort to get patches accepted. Most require some additional work before
approaching the project developer lists because of known missing feature
support. For example, the wxWidgets CMake build system is lacking support
for building a GTK version on Linux and that's used quite heavily. Once
that support is in place it would probably be worth asking them. Then of
course there'd need to be an equivalent of wx-config as this is a bash
script and doesn't work on Windows without a bash shell.

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OpenSSL-CMake build system

[Dick Hollenbeck]

> I commented this out because CMake barfs if you pass CMAKE_TOOLCHAIN_FILE as 
> a blank
> value. I left it in, but commented out for exactly this sort of feedback. 
> I've included it
> in a conditional which checks to see if CMAKE_TOOLCHAIN_FILE is blank.


Well done, perfect solution.

one extra comment line we don't need now, due to your magic and amazing build 
system work
on OPENSSL:

   # this requires that perl be installed:


Any luck getting this CMake work accepted upstream on any of your numerous 
upstream CMake
efforts?



> d) Seems to need another new line at end of file, see very bottom.
> 
> 
> > It builds on the excellent work you did on downloading
> > and building openssl,
> 
> I was passing the baton, knowing and hoping you'd step in and make it 
> work for the most
> difficult platform.  Trying to save you some initial work.
> 
> You continue to be an MVP.
> 
> Dick
> 
> 
> Excellent, this is now in place in BZR4447.
> 
> KiCad-Winbuilder 3.1 (Literally minutes old) now includes support for the GAL 
> default
> build as well as enabling FP_LIB_TABLE and GITHUB_PLUGIN so as to maximise 
> the exposure of
> those features to beta-testers. There are easy-to-configure options in 
> KiCad-Winbuilder to
> disable these options if someone wants to run the latest KiCad build without 
> them enabled.
> 
> We should now expect feedback on those features to increase.


With GITHUB_PLUGIN now available to ~ 90% of the KiCad user base (omitting 
OSX?), I now
look forward to folks putting footprint libraries on github and bragging about 
them, under
the leadership of Carl Poirier, who has scripts and know how on how to publish 
them so
that they can be "installed" by a single copy and paste through a webbrowser 
into the
fp-lib-table editor.

I look forward to that affecting my productivity in a positive way, so that I 
can spend
less time looking for footprints, and more time making boards.

I would look forward to collaboration on sharing the "pretty on github 
publishing" know
how on kicad-pcb.org in the form of documentation, and a link to that write up 
making it
to the kicad-user mailing list.  Because I think this would spur more sharing, 
and yet
again help my productivity in making boards.

Question: does google index any of the github content, or is it simply too 
much?  If yes,
then this is yet another way to find KiCad specific footprints rapidly after 
this
publishing gets some legs.  You should be able to google for

   kicad_mod 

and turn up something.




> 
> Thanks very much to Orson who did the changes necessary for KiCad-Winbuilder 
> to
> successfully build the GAL code. A quick, simple merge was all that was 
> necessary! Lovely!
> 
> Now I'm looking forward to getting some boards done, and getting some work 
> done on the
> regression testing too. Something other than build systems would be nice for 
> a while!
> CMake continues to comfort me where autotools used to kick me in the shins 
> regularly. The
> CMake documentation is also excellent, very complete and concise.
> 
> Best Regards,
> 
> Brian.


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OpenSSL-CMake build system

[Brian Sidebotham]

On 23 October 2013 14:57, Dick Hollenbeck  wrote:

>
> Brian,
>
> If it works for you, it works for me.  I want your life as easy as
> possible!  Plus if it
> works for you, it works for Windows users, and that brings them use of the
> GITHUB_PLUGIN,
> so I am happy all around.
>
>
Hi Dick,

Excellent, I'm committed these changes in BZR4447


> IMO, it is also good for openssl.  But you know how folks are with their
> build systems.
> (Folks like sticking with what they know.)
>
> Some comments:
>
> a) pcbnew/github/CMakeLists.txt will continue to use find_package( OpenSSL
> REQUIRED ) on
> linux.  This is the path of least resistance for that platform.
>
>
Agreed.


> b) The path chosen on OSX seems unclear to me, but as written,
> github/CMakeLists.txt will
> route OSX builders to find_package() as well, meaning they will have to
> install openssl in
> advance of the build.  I don't know OSX, the possibility to use your
> openssl build system
> is on the table, but just guessing, it seems they will prefer a pre-built
> package like on
> linux.
>
> c) You commented out the toolchain statement.  I know Orson and others are
> cross building
> the entire KiCad for Windows on Linux.  To me it seems we need to pass the
> CMAKE_TOOLCHAIN_FILE setting in, on the assumption that if it is blank, it
> won't break the
> native build.  You will confirm that upon re-enabling it.
>
>
I commented this out because CMake barfs if you pass CMAKE_TOOLCHAIN_FILE
as a blank value. I left it in, but commented out for exactly this sort of
feedback. I've included it in a conditional which checks to see if
CMAKE_TOOLCHAIN_FILE is blank.


> d) Seems to need another new line at end of file, see very bottom.
>
>
> > It builds on the excellent work you did on downloading
> > and building openssl,
>
> I was passing the baton, knowing and hoping you'd step in and make it work
> for the most
> difficult platform.  Trying to save you some initial work.
>
> You continue to be an MVP.
>
> Dick
>
>
Excellent, this is now in place in BZR4447.

KiCad-Winbuilder 3.1 (Literally minutes old) now includes support for the
GAL default build as well as enabling FP_LIB_TABLE and GITHUB_PLUGIN so as
to maximise the exposure of those features to beta-testers. There are
easy-to-configure options in KiCad-Winbuilder to disable these options if
someone wants to run the latest KiCad build without them enabled.

We should now expect feedback on those features to increase.

Thanks very much to Orson who did the changes necessary for
KiCad-Winbuilder to successfully build the GAL code. A quick, simple merge
was all that was necessary! Lovely!

Now I'm looking forward to getting some boards done, and getting some work
done on the regression testing too. Something other than build systems
would be nice for a while! CMake continues to comfort me where autotools
used to kick me in the shins regularly. The CMake documentation is also
excellent, very complete and concise.

Best Regards,

Brian.
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] OpenSSL-CMake build system

[Dick Hollenbeck]

On 10/22/2013 04:57 PM, Brian Sidebotham wrote:
> Hi Guys,
> 
> I attach a diff which uses a new OpenSSL-CMake project I registered on 
> Launchpad to
> provide a CMake build system on-top of OpenSSL. I started with the LuaDist 
> project's CMake
> system and patched it to work with the OpenSSL 1.0.1e release.
> 
> This means that all of the "if( MINGW )" tests and the like in
> CMakeModules/download_openssl.cmake go away and we end up with a common build 
> system for
> all systems. It should work for all systems.
> 
> Hopefully we can use this build system instead of the horrible PERL one. It's 
> probably not
> the most complete build system in the world - but it appears to do the job 
> admirably. I
> tried "openssl speed" to stress test the library build with the CMake build 
> system and
> everything looked good.
> 
> I need to test it on Linux, and I don't have a MAC box to test on, but I 
> can't see
> anything that shouldn't work - everything's pretty generic.
> 
> It's a shame launchpad release file URL's are so verbose - I didn't bother 
> trying to put
> the version number variable in it, it's probably easier to just change that 
> URL when the
> MD5 and version variables are changed.
> 
> Dick, does this look good to you? 

Brian,

If it works for you, it works for me.  I want your life as easy as possible!  
Plus if it
works for you, it works for Windows users, and that brings them use of the 
GITHUB_PLUGIN,
so I am happy all around.

IMO, it is also good for openssl.  But you know how folks are with their build 
systems.
(Folks like sticking with what they know.)

Some comments:

a) pcbnew/github/CMakeLists.txt will continue to use find_package( OpenSSL 
REQUIRED ) on
linux.  This is the path of least resistance for that platform.

b) The path chosen on OSX seems unclear to me, but as written, 
github/CMakeLists.txt will
route OSX builders to find_package() as well, meaning they will have to install 
openssl in
advance of the build.  I don't know OSX, the possibility to use your openssl 
build system
is on the table, but just guessing, it seems they will prefer a pre-built 
package like on
linux.

c) You commented out the toolchain statement.  I know Orson and others are 
cross building
the entire KiCad for Windows on Linux.  To me it seems we need to pass the
CMAKE_TOOLCHAIN_FILE setting in, on the assumption that if it is blank, it 
won't break the
native build.  You will confirm that upon re-enabling it.

d) Seems to need another new line at end of file, see very bottom.


> It builds on the excellent work you did on downloading
> and building openssl, 

I was passing the baton, knowing and hoping you'd step in and make it work for 
the most
difficult platform.  Trying to save you some initial work.

You continue to be an MVP.

Dick



but it also wipes out quite a bit of work you'd already done. This
> does mean we are in control of the build in the same way on all platforms 
> though, and of
> course, it's a CMake build system too!
> 
> I will try to contact the OpenSSL guys and see if they are in any way keen to 
> have a CMake
> build system contribution.
> 
> Best Regards,
> 
> Brian.
> 
> openssl-cmake-kicad.diff
> 
> 
> === modified file 'CMakeModules/download_openssl.cmake'
> --- CMakeModules/download_openssl.cmake   2013-09-22 03:24:11 +
> +++ CMakeModules/download_openssl.cmake   2013-10-22 21:20:53 +
> @@ -29,60 +29,19 @@
>  
> #--
>  
>  set( OPENSSL_RELEASE "1.0.1e" )
> -set( OPENSSL_MD5 66bf6f10f060d561929de96f9dfe5b8c ) # re-calc on every 
> RELEASE change
> +set( OPENSSL_MD5 08bec482fe1c4795e819bfcfcb9647b9 ) # re-calc on every 
> RELEASE change
>  
>  
> #
>  
> -unset( PIC_FLAG )
> -set( CFLAGS CFLAGS=${CMAKE_C_FLAGS} )
> -
> -if( MINGW ) # either MINGW or cross compiling?
> -if( CMAKE_SIZEOF_VOID_P EQUAL 4 )
> -set( MINGW32 true )
> -set( MACHINE x86_32 )
> -elseif( CMAKE_SIZEOF_VOID_P EQUAL 8 )
> -set( MINGW64 true )
> -set( MACHINE x86_64 )
> -endif()
> -
> -if( MINGW32 )
> -set( HOST "--host=i586-pc-mingw32" )
> -elseif( MINGW64 )
> -set( HOST "--host=x86_64-pc-mingw32" )
> -endif()
> -
> -set( CC "CC=${CMAKE_C_COMPILER}" )
> -set( RANLIB "RANLIB=${CMAKE_RANLIB}" )
> -set( AR "AR=${CMAKE_AR}" )
> -else()
> -set( PIC_FLAG -fPIC )
> -endif()
> -
> -string( TOLOWER ${CMAKE_HOST_SYSTEM_NAME} build )
> -
> -# Force some configure scripts into knowing this is a cross-compilation, if 
> it is.
> -set( BUILD --build=${CMAKE_HOST_SYSTEM_PROCESSOR}-pc-${build} )
> -
> -
> -# http://www.blogcompiler.com/2011/12/21/openssl-for-windows/
> -# http://qt-project.org/wiki/Compiling-OpenSSL-with-MinGW
>  set( PREFIX ${DOWNLOAD_DIR}/openssl-${OPENSSL_RELEASE} )
>  
> -unset( CROSS )
> -if( MINGW32 )
> -

[Kicad-developers] OpenSSL-CMake build system

[Brian Sidebotham]

Hi Guys,

I attach a diff which uses a new OpenSSL-CMake project I registered on
Launchpad to provide a CMake build system on-top of OpenSSL. I started with
the LuaDist project's CMake system and patched it to work with the OpenSSL
1.0.1e release.

This means that all of the "if( MINGW )" tests and the like in
CMakeModules/download_openssl.cmake go away and we end up with a common
build system for all systems. It should work for all systems.

Hopefully we can use this build system instead of the horrible PERL one.
It's probably not the most complete build system in the world - but it
appears to do the job admirably. I tried "openssl speed" to stress test the
library build with the CMake build system and everything looked good.

I need to test it on Linux, and I don't have a MAC box to test on, but I
can't see anything that shouldn't work - everything's pretty generic.

It's a shame launchpad release file URL's are so verbose - I didn't bother
trying to put the version number variable in it, it's probably easier to
just change that URL when the MD5 and version variables are changed.

Dick, does this look good to you? It builds on the excellent work you did
on downloading and building openssl, but it also wipes out quite a bit of
work you'd already done. This does mean we are in control of the build in
the same way on all platforms though, and of course, it's a CMake build
system too!

I will try to contact the OpenSSL guys and see if they are in any way keen
to have a CMake build system contribution.

Best Regards,

Brian.


openssl-cmake-kicad.diff
Description: Binary data
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp