www.libssh2.org | Daily snapshots | Mailing list archive | Docs | Examples | github

Archive Index This month's Index

Subject: CMake

CMake

From: Alexander Lamaison <swish_at_lammy.co.uk>
Date: Sat, 6 Dec 2014 00:34:41 +0000

You may recall that back in March I promised to convert the libssh2
build system to CMake 'soon'. Well, 9 months later, it is more or
less complete: https://github.com/alamaison/libssh2/tree/cmake. I
would greatly appreciate your feedback and help with testing on the
platforms that matter to you.

The goal is to match or exceed every relevant feature of the autotools
system like-for-like, so, unless otherwise stated in this email,
assume that any missing functionality is a bug. Please report it.

CMake, however, is fundamentally different from autotools, so some
features (for example, building source distributions, aka `make dist`)
aren't relevant anymore and aren't specifically catered for. The
README should get you started but, if you need help getting accustomed
to CMake, I'm very happy to answer any questions you have.

tl;dr
- A version of libssh2 using CMake is available at
  https://github.com/alamaison/libssh2/tree/cmake
- Please test

Platform support
================

I've tested the build with the three major platforms, Linux (GCC
4.6.3, Clang 3.4), Windows (VS2005, VS2008) and MacOS X (AppleClang
6.0.0), in a variety of configurations. I've also set up continuous
integration using Travis CI [2], so libssh2 is continually tested on
Linux in 32 combinations of OpenSSL/Libgrypt, 32-bit/64-bit,
GCC/Clang, shared/static, with/without zlib.

I've not been able to test with VMS or Netware, two of the more
unusual platforms that we support. I don't have access to that kind
of hardware, so any help testing would be greatly appreciated.

Why?
====

If you are wondering what benefits this change brings, there is plenty
of discussion about this out there about the merits of CMake, but the
main reasons that it makes sense for libssh2 are:

1) We were trying (failing?) to maintain build files by hand for
   non-autotool platforms such as Windows. As well as being a waste
   of effort, these custom jobds rarely kept up with libssh2
   development. For example, they are hardcoded to use OpenSSL even
   though libssh2 supports multiple crypto backends. Using CMake we
   are now able to build libssh2 for all the common platforms and
   crypto backends using a single build configuration. When it is
   updated to accomodate a new feature, all platforms feel the
   benefit simultaneously.

2) Even if we supported your _platform_, our build setup restricted
   your choice of development environment to GNU Makefiles on Unix or
   Visual Studio 6 on Windows. Using CMake we can now generate the
   necessary files for your choosen environment: GNU Makefiles, Visual
   Studio 2005-2014, Xcode, Eclipse CDT ... and many more [1].

3) CMake makes it easy to automatically fetch and build a projects as
   a component of a larger CMake project. This a big deal for a
   library.

4) For better or worse, CMake has won the latest war of the C/C++
   build systems. This makes it the focus of new innovation and the
   support community is very active. As more and more projects are
   adopting it, they can take advantage of 3).

What doesn't work yet?
======================

I've already mentioned that I've not been able to test VMS or Netware,
so I'm going to assume that doesn't work simply because I've not done
anything with the code in the `vms` and `nw` directories yet. It's
possible that that code is redunant for CMake but, if not, I'll adjust
the build files if a VMS/Netware user can explain to me what they
need.

Compiling with OpenWatcom works but I'm having trouble linking against
OpenSSL. Using WinCNG also doesn't compile and it seems to be a SDK
issue. Can anyone familiar with that compiler help me understand what
extra steps are necessary? Another issue with OpenWatcom is that
version 1.9 doesn't work if CMake is installed in a path containing
spaces or parentheses. The bug is with the compiler, but I've filed a
CMake issue to request a workaround [3].

Libssh2 inherited some complex compiler warning settings from cURL.
I've not ported this to CMake yet because I want to understand the
goal first, so that I can do this in a cross-platform way. For now,
I've turned on -Wall or /W4. Would anyone like other warnings
enabled? If so, which?

Any changes committed to develop since I branched are not yet
integrated into the cmake branch. That's the next job.

Thanks for listening. Fire away.

Alex

[1] http://www.cmake.org/cmake/help/v3.1/manual/cmake-generators.7.html
[2] https://travis-ci.org/alamaison/libssh2
[3] http://www.cmake.org/Bug/view.php?id=15279

-- 
Swish - Easy SFTP for Windows Explorer (http://www.swish-sftp.org)
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2014-12-06

the libssh2 team