[
https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14599866#comment-14599866
]
Alex Clemmer edited comment on MESOS-898 at 6/24/15 6:17 PM:
-------------------------------------------------------------
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 -- I don't want to
let the commit hang too long, but I am also new to the community, and I want to
give people a chance to build consensus that this commit is at least
directionally correct. :)
was (Author: hausdorff):
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 -- I don't want to
let the commit hang too long, but I am also 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)
