[zeromq-dev] zmq cmake patch

[George Neill]

Malo,

> In attachment is patch against rev. 641 it adds only very basic support for
> cmake (only zmq and zmq_server is build on Linux).
> It is based on your work and should be seen as a model and starting point.
> I'm "few hours" cmake user and hence your experience is important for us,
> anyway here are my notes to cmake support.
>
> 1. At first we would like to use as many macros provided by cmake as
> possible.
> Searching for thread library can be done with find_package Threads. There's
> FindSDL.cmake and FindJava.cmake in Modules directory and we should
> presumably use those.

While a handful of Find*.cmake packages are distributed with cmake; I
don't believe kitware maintains them.  I have found most of these
package scripts -are- useful if you plan on supporting just the
win/linux/mac platforms.  but in the end I have found myself copying
them local and modifying them as soon as i move on to support
different platforms.

As an example, the default in FindThreads.cmake for HPUX is to blindly
use CMA threads and there's no way to override it without making a
local copying and changing.  IMO there probably should be a
FindNativeThreads.cmake and FindPosixThreads.cmake and
FindThreads.cmake should call either of those based on some flags.

For SDL, FindSDL.cmake implicitly pulls in FindThreads even when they
may not be necessary.
For Java, FindJNI.cmake checks for far more than what is needed to
build zmq ... plus it will only work for win/mac/linux (even if you
set ENV vars)

The unicap and socket find scripts didn't exist ... so as a starting
point, I created those.  The socket one, quite honestly could be
considered a platform check.

In summary, I believe the worthiness of each Find*.cmake package
inclusion should be looked at, but I don't necessarily think we should
just implicitly use them.  I consider each more of a starting point.
Of course, in the end, i'd like to contribute back whatever we find to
the maintainers of each script.

> 2. Add as less new files as possible.
> I have moved code from zmq_platform_checks.cmake and
> zmq_cmake_policies.cmake into main CMakeLists.txt file they are easy to spot
> and modiffy. Note that changes should be able to make even user which is not
> so familiar with cmake and with no so much time to explore all the cmake
> hierarchy.

Your call.  As a developer, I believe they are _easier_ to work with
split in to separate files.  As the project grows, I believe you'll
find having those split out would be better (same with c++ or any
other language for that matter).  Your argument could be solved with
some decent documentation.

> 3. If something is getting wrong stop the configure process.
> For example if you are on unsupported platform or some library was not found
> all the process should be stopped with some warning.

I agree for the most part. I would argue it should only stop on
-required- items ... basically anything detrimental to zmq working.
So for example, one would just spit out a warning when trying to build
the camera example ... not stop the build.  But, again, a tunable
could be set -D"STOP_ON_WARNING=ON" or something like that.  Do what
you feel is necessary.

> 4. We prefer to build shared libraries by default.

Ok.  That's fine, we can just change the default BUILD_SHARED_LIBS
variable to ON.

BTW, if you have not realized it yet, this is probably one of the
biggest *potential* issues with converting over to use cmake.  I don't
think it's a big deal, but some probably do.  In order to build static
and shared libraries for the same target you can do one of two things.

1.  Do two builds, on with BUILD_SHARED_LIBS turned on and the other
with it off.
2.  Give your shared/archive libraries a suffix (different target
names).  e.g.  libzmq_static.a,  libzmq_shared.so

> 5. Do not make it look ZMQ specific.
> Your are creating macros zmq_find_unicap.cmake which can be acctualy
> FindUnicap.cmake and used with find_package interface.

I specifically chose -not- to use the FIND_PACKAGE command for these
because 1.  I wanted it to be clear these -are- specific to zmq  2. I
don't like the naming convention enforced and 3. I don't like mixing
camelhump and underbar notation.

Silly, probably, but I don't feel you lose much by doing an INCLUDE
vs. a FIND_PACKAGE  (I could be wrong).

> Do not take an offence, maybe I have missed something and you have good
> reason to do thing the way you do it, we just need a little explanation.
> Anyway as soon as you are signing Copyright Assignment and License we will
> create you branch where we can continue work on cmake patch.

No offense at all, infact I always try to be in learn mode ... so if
you find a better way to do it please share.  We'll disagree on some
but that's fine.  I have used cmake for about a year now, and still
consider myself a rookie with it.  The above are just my opinions and
I am not associated in any way with kitware or it's maintainers.

> Believe that we have spend a long time to fight with autotools and cmake
> seems for us like a nice option to move forward.

Same here ... and honestly why choose to use cmake today.  You will
also find the folks at kitware provide great community support as
well.

Thanks,
George.