[
https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Gavin updated MESOS-898:
------------------------
Comment: was deleted
(was: www.rtat.net)
> 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: Joseph Wu
> Priority: Major
> Labels: build, cmake, mesosphere
>
> 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
(v7.6.3#76005)
