CMake and (eventually) deprecating the autotools build

[Joseph Wu <jo...@mesosphere.io>]

Hi Devs!

The CMake build system for Mesos is now complete enough for wider
consumption.  The plan is to review all the differences between the
CMake and Autotools build systems and eventually deprecate the
Autotools build system.

A few of us are already using CMake exclusively for development.  But
we'd like to have more developers using it *before we start talking
about deprecation*.


Here is a summary of the known differences:

Missing features:
* CMake does not build Java artifacts at the moment.  Since the most
widely-used frameworks (Aurora, Marathon, etc) rely on this, we will
prioritize getting this done.
* CMake currently does not let you specify the exact system dependency
to use.  i.e. --with-ssl=... --with-boost=... etc.  Instead, CMake
either uses the bundled versions or automatically finds the system
locations.  This is a blocker for CMake adoption by DC/OS.
* CMake does not have an install target at the moment.  One of the top
priority things to get done.
* CMake does not build the port isolator module at the moment.
* CMake does not have an option to install the module dependencies at
the moment.
* CMake does not work on FreeBSD at the moment.

Features left out on purpose:
* CMake does not generate artifacts for Python.  We feel the Autotools
deprecation will likely run near/alongside the push towards using the
V1 HTTP APIs.  And there is already an HTTP API library for Python:
https://github.com/douban/pymesos
* CMake does not build the old CLI executables (src/cli/mesos.cpp and
src/cli/resolve.cpp) under the assumption that we will replace those
in the near future.
* CMake does not support installing test binaries, because the feature
appears to be unused.

New features:
* CMake builds on Windows!
* CMake supports packaging sources.  For example, you can do `cmake ..
&& make package_source` to generate the autotools equivalent of `make
dist`.
* CMake supports packaging binaries.  For example:

  * To generate debs and rpms: `cmake .. -DCPACK_BINARY_DEB=1
-DCPACK_BINARY_RPM=1 && make package`
  * On Windows, to build a graphical installer: `cmake ..
-DCPACK_BINARY_NSIS=1 && make package`
  * On OSX, to build .dmg and interactive installers: `cmake ..
-DCPACK_BINARY_OSXX11=1` and `-DCPACK_BINARY_DRAGNDROP=1 && make
package`

* More granular build targets.  For example, if you're working on
libprocess, you can use `make libprocess-tests` instead of babysitting
`make check`.
* [Upcoming] Precompiled headers, which should speed up the build dramatically.
* [Upcoming] We will be combining some aspects of Mesosphere's OSS
packaging repo [1] so that binary packages will contain service
definitions, as well as binaries.


Please let us know if you have any comments, concerns, or requests!

And please do try it out:
cmake .. && cmake --build .

The JIRA tracking the CMake build system is here:
https://issues.apache.org/jira/browse/MESOS-898

Thanks!
~Joseph


[1] https://github.com/mesosphere/mesos-deb-packaging

Re: CMake and (eventually) deprecating the autotools build

[Alex Rukletsov <al...@mesosphere.com>]

A tip for ccache users. Recent versions of CMake allow to set
CMAKE_{CXX|C}_COMPILER_LAUNCHER=<path-to-ccache>. For example, `cmake
-DCMAKE_CXX_COMPILER_LAUNCHER=/usr/local/bin/ccache
-DCMAKE_C_COMPILER_LAUNCHER=/usr/local/bin/ccache`.

On Tue, Mar 14, 2017 at 6:15 PM, Joseph Wu <jo...@mesosphere.io> wrote:

> Hi Devs!
>
> The CMake build system for Mesos is now complete enough for wider
> consumption.  The plan is to review all the differences between the
> CMake and Autotools build systems and eventually deprecate the
> Autotools build system.
>
> A few of us are already using CMake exclusively for development.  But
> we'd like to have more developers using it *before we start talking
> about deprecation*.
>
>
> Here is a summary of the known differences:
>
> Missing features:
> * CMake does not build Java artifacts at the moment.  Since the most
> widely-used frameworks (Aurora, Marathon, etc) rely on this, we will
> prioritize getting this done.
> * CMake currently does not let you specify the exact system dependency
> to use.  i.e. --with-ssl=... --with-boost=... etc.  Instead, CMake
> either uses the bundled versions or automatically finds the system
> locations.  This is a blocker for CMake adoption by DC/OS.
> * CMake does not have an install target at the moment.  One of the top
> priority things to get done.
> * CMake does not build the port isolator module at the moment.
> * CMake does not have an option to install the module dependencies at
> the moment.
> * CMake does not work on FreeBSD at the moment.
>
> Features left out on purpose:
> * CMake does not generate artifacts for Python.  We feel the Autotools
> deprecation will likely run near/alongside the push towards using the
> V1 HTTP APIs.  And there is already an HTTP API library for Python:
> https://github.com/douban/pymesos
> * CMake does not build the old CLI executables (src/cli/mesos.cpp and
> src/cli/resolve.cpp) under the assumption that we will replace those
> in the near future.
> * CMake does not support installing test binaries, because the feature
> appears to be unused.
>
> New features:
> * CMake builds on Windows!
> * CMake supports packaging sources.  For example, you can do `cmake ..
> && make package_source` to generate the autotools equivalent of `make
> dist`.
> * CMake supports packaging binaries.  For example:
>
>   * To generate debs and rpms: `cmake .. -DCPACK_BINARY_DEB=1
> -DCPACK_BINARY_RPM=1 && make package`
>   * On Windows, to build a graphical installer: `cmake ..
> -DCPACK_BINARY_NSIS=1 && make package`
>   * On OSX, to build .dmg and interactive installers: `cmake ..
> -DCPACK_BINARY_OSXX11=1` and `-DCPACK_BINARY_DRAGNDROP=1 && make
> package`
>
> * More granular build targets.  For example, if you're working on
> libprocess, you can use `make libprocess-tests` instead of babysitting
> `make check`.
> * [Upcoming] Precompiled headers, which should speed up the build
> dramatically.
> * [Upcoming] We will be combining some aspects of Mesosphere's OSS
> packaging repo [1] so that binary packages will contain service
> definitions, as well as binaries.
>
>
> Please let us know if you have any comments, concerns, or requests!
>
> And please do try it out:
> cmake .. && cmake --build .
>
> The JIRA tracking the CMake build system is here:
> https://issues.apache.org/jira/browse/MESOS-898
>
> Thanks!
> ~Joseph
>
>
> [1] https://github.com/mesosphere/mesos-deb-packaging
>