[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599866#comment-14599866 ]
Alex Clemmer commented on MESOS-898: ------------------------------------ Only a few people have given a quick once-over look to the prototype [CMake-based build system for libprocess|https://github.com/hausdorff/mesos/commit/073d42cea1bed8e7fb801f59685f52d3be06e510?diff=unified], but they have been pretty positive, so I would like to target EOD tomorrow (i.e., Th, June 24th) for posting something to ReviewBoard. This slight delay is mainly because I am new to the community, and I want to give people a chance to build consensus that this commit is at least directionally correct. :) > Introduce CMake as an alternative build system. > ----------------------------------------------- > > Key: MESOS-898 > URL: https://issues.apache.org/jira/browse/MESOS-898 > Project: Mesos > Issue Type: Epic > Components: build > Reporter: Timothy St. Clair > Assignee: Alex Clemmer > Labels: build > > This is a rather substantial undertaking, so I would want upstream > debate+buy-in prior to full commitment. The basic premise is: upstream > rebundles several of its dependencies in part to tightly control its stack. > This is not out of the norm, but in order to be picked up by distribution > channels it needs to built against system dependencies, and rebundling is > strictly forbidden. Given that the mesos primary target platform are > data-center distributions such as RHEL/CENTOS/SL it makes sense to still have > bundling support for those who do not have dependencies in their channels > "yet". This is where cmake can be win with it's uber macros > (http://www.cmake.org/cmake/help/v2.8.8/cmake.html#module:ExternalProject). > I do not know of any equivalent in the autotools world, other then to brew > your own solution. I've done this type of work in the past, and completely > transformed condor and would leverage a lot of the work that was done there. > I currently have a tracking branch where I've started this work, but before I > go off into the woods, it makes sense to have a debate in public. > The primary benefits are: > 1. Enable downstream channels to easily distro without carrying a large patch > sets. > 2. Still support existing "non-proper" distribution methods. > 3. Harden / future proof dependent interfaces. > Side Benefits: > Audit current build mechanics. > - Presently the language specific binding are not installed. (.py & .jar) > - make -jX currently fails > - optionally look in arm support. > Costs: > 1. Time > 2. Potential temporary destabilization > 3. Infrastructure around build+test may need to change. -- This message was sent by Atlassian JIRA (v6.3.4#6332)