[nanomsg] Re: started on CMake unification
- From: Ben Swift <ben@xxxxxxxxxxx>
- To: nanomsg@xxxxxxxxxxxxx
- Date: Tue, 24 Mar 2015 18:17:53 +1100
Hi folks
I might be missing something here, but won't we still be able to
generate the configure and make files from cmake, e.g. with
cmake -G "Unix Makefiles"
so if you're already delivering the nanomsg sources (or some additional
build script) to them then you can just include these files in your
distribution tarball?
Cheers,
Ben
Alexander Williams <alex@xxxxxxxxxxxxxxxx> writes:
> 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:
