[nanomsg] started on CMake unification
- From: Garrett D'Amore <garrett@xxxxxxxxxx>
- To: nanomsg <nanomsg@xxxxxxxxxxxxx>
- Date: Mon, 23 Mar 2015 19:30:13 -0700
So some of you may already know some of this.
It turns out that I’ve started the work to move libnanomsg away from autotools
to just using cmake for building. (And can I say that while the cmake configs
are nice, the documentation for cmake is atrocious!)
The motivation here is to get to a single build system that drives everything.
autotools simply cannot service the entire community, as it needs a mostly
unix-like environment to run in. It has dependencies on GNU m4, and a
reasonable bash-like shell. This sort of precludes operation on Windows.
cmake can build Makefiles for all systems that I know about. It generates
Makefiles on UNIX systems, but also can do project files for various IDEs
(MSVC, Xcode, etc.)
Frankly, libnanomsg’s tests for various features have some bugs, and that needs
work. I’m loathe to work in auto*. At the time, I also didn’t realize we had
a functional “make check” target (make test isn’t a functional target) in
autotools. So the way tests get executed is different on different platforms
too. Argh. Anyway….
Upshot is I’ve spent some time, and done most of the work — from what I can
tell this generates (at least on my MacOS X and illumos systems) correct builds
of nanomsg. The work is in my own branch here:
https://github.com/gdamore/nanomsg/tree/cmake
<https://github.com/gdamore/nanomsg/tree/cmake>
There are a few things missing or still to be done:
a) Documentation installation is not performed (via asciidoc or anything else).
b) The symbolic links for the nn_* programs that point to nanocat are not yet
made. (symbolic links are not portable, btw.)
c) The library ABI version is probably not quite right — libtool has a crapload
of platform-specific craziness that results in quite different .so.* suffixes
for different platforms — Darwin, Linux, FreeBSD, and illumos/Solaris are all
different! I’ve instead opted for a simpler solution — taking the current
version 2.1.2 which generally results in .so.2-> pointing to .so.2.1.2 etc. I
believe that this result is sensible for all systems that support ABI
versioning. (Notably, libtool’s approach is also incredibly naive, since it
doesn’t understand rich versioning expressed in mapfiles, etc.) I’m open, btw,
to suggestions from other experts here, particularly people coming from other
platforms or that are likely to be impacted if the .so version changes.
d) There are a few —enable-xxx things that could be done which are missing.
Notably the use of getaddrinfo_a for asynchronous name resolution on linux.
(Its enabled by default, but I’ve not validated it.)
e) Testing that this actually works on Linux and various other platforms. I’d
appreciate help here.
f) Clean up of autotools artifacts. I’ve started that, but the process is far
from complete. Mostly for now I keep them for history.
g) Add CPack targets to build binary packages for the big-three (windows,
linux, macos) — windows is already there, although I’m told it doesn’t build
properly right now — I’ll probably take a look at that once I get this up to a
Windows box.
And now, the other thing — which is whether people are going to be upset if
autotools support goes away. Here are my thoughts on this:
1. As indicated supporting multiple build/configure systems is a PITA.
I don’t want to keep doing it.
2. Supporting Windows requires Cmake
3. cmake is available for most platforms, and can be used to cross
compile (I suspect it can be used to cross-configure without cross-compiling,
but that’s a different matter).
4. some have griped that cmake is in C++, which is onerous. but that
requirement is only placed upon the *build* system, and frankly your compilers
probably have C++ in them anyway — and autotools has a more onerous dependency
graph actually (m4, shell, plus libtool, perhaps pkg-config which brings in
glib, etc.) cmake at least is self-contained.
5. unfortunately, cmake does require that folks building the library
have cmake. that’s not most library users in a distribution setting, but it is
most developers. But installation of cmake from source is a one-time task of a
few minutes, not worse really than installing Gnu m4 from source (provided you
do have a C++ compiler available.)
So, if you’re going to be seriously inconvenienced by the removal of autotools
and a switch to cmake support, I’d like to know about it. I’d like to know
exactly why this is such a painful process, especially I’d like to know if
there are things I can do to mitigate the pain.
And, if there are any cmake or autotools experts in the audience who want to
lend a hand, I’d love to hear from them too!
- Garrett
Other related posts:
