[
https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14628493#comment-14628493
]
Alex Clemmer edited comment on MESOS-898 at 7/15/15 6:27 PM:
-------------------------------------------------------------
Hey folks. [~tstclair] gave some useful feedback, and I posted 2 commits to RB.
Happy to discuss it here or there. The reviews are at:
EDIT: Derp, I pasted the same link twice. Fixed!
(1) https://reviews.apache.org/r/36513/
(2) https://reviews.apache.org/r/36514/
was (Author: hausdorff):
Hey folks. [~tstclair] gave some useful feedback, and I posted 2 commits to RB.
Happy to discuss it here or there. The reviews are at:
(1) https://reviews.apache.org/r/36514/
(2) https://reviews.apache.org/r/36514/
> 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)
