[nanomsg] Re: started on CMake unification
- From: Alexander Williams <alex@xxxxxxxxxxxxxxxx>
- To: "nanomsg@xxxxxxxxxxxxx" <nanomsg@xxxxxxxxxxxxx>
- Date: Tue, 24 Mar 2015 06:44:30 +0000
Hi Garrett,
My current FFI-bindings (PicoLisp) contain a very simple script for users
to build the nanomsg shared library. It's along the lines of: ./configure
--enable-shared && make;
Switching to CMake would require them to either install cmake or obtain a
pre-built shared lib. I understand CMake is much better for developer
sanity, but for end-users it's not. I'm not certain if switching would be a
good idea if we burdened them with this additional requirement.
In fact, the main reason I selected nanomsg was due to the ease and
simplicity of building the shared library. CMake would cancel that primary
requirement.
Personally I don't like the idea.
On Tue, Mar 24, 2015 at 2:30 AM, Garrett D'Amore <garrett@xxxxxxxxxx> wrote:
> 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
>
> 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:
