Archived

This forum has been archived. Please start a new discussion on GitHub.

Ice support for CMake

Hi,

Building cross-platform applications using Ice is difficult, particularly on Windows where the ZeroC builds use different bin and lib directories which vary from release to release, making it hard to automatically identify and use the correct versions to match the version of visual studio.

I've recently implemented "full" support for Ice in CMake, which can be found here:
http://cmake.org/gitweb?p=cmake.git;a=blob_plain;f=Modules/FindIce.cmake;hb=refs/heads/next

This is currently under final review before it goes onto the master branch. This will allow easy building and linking of Ice-using projects with CMake on any platform. It's been tested on Linux, MacOSX, FreeBSD and Windows, using multiple versions of Ice and (on Windows) Visual Studio versions, directly supporting Ice 3.3.0 to 3.5.1 via autodetection, or of any version by manually specifying the installation root. On Linux, MacOS and FreeBSD, it supports the install paths of the Debian/Ubuntu packages, MacOS homebrew ice package and BSD devel/ice port, respectively, as well as the official ZeroC packages e.g. the RPMs. So it should work across the board with pretty much every build of Ice available.

If you're using Windows, the Visual Studio generator version and bitness is used to detect and use the correct bin and lib directory which matches the VS version in use (supports autodetection of VS2005 to VS2014). And it picks all the install paths out of the Registry, so it will autodetect and use any installed ZeroC package, preferring the most recent version, to satisfy the user's requirements.

To use, just add to your cmake file, for example:
find_package(Ice 3.4.0 REQUIRED Ice IceUtil Glacier2)

and this will find an Ice version greater than or equal to 3.4.0, and find the Ice, IceUtil and Glacier2 libraries which are then made available as Ice_LIBRARIES for linking. You can of course adjust the minimum version and required libraries to suit your project. It identifies all of the slice2xxx programs, includes, slice includes and libraries. All the options and variables are documented in the above link.


While this solves the problem for all previously released versions of Ice since 3.3, it doesn't properly support future Ice releases, at least for the case where autodetection is required. What would be really useful here would be if future ZeroC builds could consider providing a cmake "package configuration script" which cmake can pick up and read to automatically discover the details of the release. See: cmake-packages(7) — CMake 3.0.1 Documentation This would be vastly less complex than the above script, and would essentially just need to set the same set of Ice_* variables from the above script to their locations in the ice directory, which could pick out the correct library versions for visual studio like the above script does. The script would be initially found by setting CMAKE_PREFIX_PATH so that it's discovered by cmake when using find_package(Ice); on Linux/MacOS/FreeBSD these can install into the default cmake path so will work out of the box when installed in /usr or /usr/local. This would make future Ice releases immediately usable by CMake users on all platforms. I'd certainly be happy to assist with doing this if you would like to add such support.


Regards,
Roger

Comments

  • What an excellent effort. I hope it makes it in ok.
  • Hi Andrew,

    Thanks for the kind words. This has now been reviewed and merged upstream and so should be distributed with cmake 3.1. It is available on the master branch, or via gitweb:

    www.cmake.org Git - cmake.git/blob - Modules/FindIce.cmake

    It will work with cmake 3.0 or later, or (with a small patch) with cmake 2.8 or later:

    https://github.com/openmicroscopy/openmicroscopy/blob/develop/components/tools/OmeroCpp/cmake/FindIce.cmake


    Kind regards,
    Roger
  • CMakeLists.txt example?

    First off, I can't thank you enough for putting together cmake support for Ice. Being a windows dev type my whole life and now trying to develop c++ linux apps, I lack a lifetime of being familiar with ever growing capabilities of Makefiles. I spend more time setting up a development environment than developing whatever I am working on. Very frustrating.

    I have gotten CentOS 7 (64-bit) + CMake 3.1.0-rc2 + eclipse 4.4.1 + Ice 3.5.1 running under Parallels 10.1.1 on a MacBook Pro running OSX Yosemite. I'm happy to help anyone trying to build a similar environment.

    What I could really use though is an example CMakeLists.txt, say one that works with one of the simple Ice demo examples - to more easily figure out how to slice2cpp as part of the build process.
  • I found an issue with FindIce with an install on Centos7 from the zeroc-ice-el7.repo repository. The libraries are in /usr/lib64 (or /usr/lib) and this path is not in the find_library() hint list.
  • Examples

    Hi Brian,

    Firstly, regarding the "lib64" directory, I think that should be on your library search path (see CMAKE_SYSTEM_PREFIX_PATH and CMAKE_PREFIX_PATH in cmake-variables(7)). This isn't AFAIK a problem with the FindIce macro; it's a general cmake setup issue for finding libraries which would affect all library searches.

    Regarding running slice2cpp, you can find a (unfortunately complex) example here:

    https://github.com/openmicroscopy/openmicroscopy/blob/develop/components/tools/OmeroCpp/CMakeLists.txt

    See the "icegen" function at line 167 and its use at 198-205. Basically, this takes three variable names: a list of ice sources, and variables to store the generated source and header names in. You can then use the latter two in your library/exectable targets as sources. For each file it adds a target to do the slice2cpp generation and also installs the header.

    Also see the gensrc target on line 397 which is useful for testing.

    The icegen function is specific to this project; it makes certain assumptions about the source layout and install locations. However, you could easily copy this and tweak it to fit your needs.


    Kind regards,
    Roger
  • CMake variables

    Correction: I meant to past CMAKE_SYSTEM_LIBRARY_PATH in the last post, not CMAKE_SYSTEM_PREFIX_PATH.
  • CMake support for lib64

    You might find this helpful and of interest:

    FIND_LIBRARY_USE_LIB64_PATHS
    0011964: Handle lib64 library on Linux - MantisBT

    Regards,
    Roger
  • I can't thank you enough. If you happen to be near Chicago, the drinks are on me.
  • fix for FindIce.cmake for unsupported if() test for TRUE

    I believe I have found the source of the problems. (at least on CentOS 7) There are if tests in FindIce.cmake that are of the form

    if("${variable_name}")
    do stuff
    endif()

    For some reason in CMake 3.1 is not following the rule where a constant that is not one of the defined ones ("0" "1" "TRUE" "FALSE" etc...) if should evaluate as a variable where a non false constant is considered to be TRUE. Instead it is evaluating as FALSE.

    An interim fix would be to remove the quotes in FindIce.cmake. I will go see about submitting a bug report with CMake.
  • FindIce.cmake needs updating to be compatible with the latest policy changes

    set(fooref "foo")
    set ("${fooref}" "some string")
    if ("${fooref}")
    message(status "string is true")
    endif()

    produces this output:

    CMake Warning (dev) at CMakeLists.txt:3 (if):
    Policy CMP0054 is not set: Only interpret if() arguments as variables or
    keywords when unquoted. Run "cmake --help-policy CMP0054" for policy
    details. Use the cmake_policy command to set the policy and suppress this
    warning.

    Quoted variables like "foo" will no longer be dereferenced when the policy
    is set to NEW. Since the policy is not set the OLD behavior will be used.
    This warning is for project developers. Use -Wno-dev to suppress it.

    statusstring is true
  • cmake 3.1 bug

    Note that the issue with FindIce with cmake 3.1 was fixed in cmake git by the cmake developers and it will be in the next cmake point release.

    I'll add support for Ice 3.6 soon as well. Is the list of supported Visual Studio versions in the beta going to be the same as for the 3.6.0 release? If so, I'll add support for 3.6b and 3.6.0 at the same time.
  • matthew
    matthew NL, Canada
    Yes, we won't change compiler support from beta to release.