[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14597899#comment-14597899 ]
haosdent commented on MESOS-898: -------------------------------- LLVM and KDE move to cmake several years ago. In fact, I try to use [am2cmake|http://www.cmake.org/Wiki/CMake#automake.2Fautotools.2Fautoconf] to convert current automake files one month ago. But the convert result is ugly, I think it's better to convert manually. I think the largest advantage to use CMake is: CMake could help you [generate IDE project files|http://www.cmake.org/cmake/help/v3.0/manual/cmake-generators.7.html]. After add CMake support, we just need execute {code}cmake -G "Your IDE name"{code} IDE name could be visual studio, xcode, CodeBlocks, Eclipse, CodeLite, QtCreator or other support IDE here. And then it could be imported by you ide. > 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)