[jira] [Comment Edited] (MESOS-898) Transform and audit mesos build process

["Cosmin Lehene (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14245796#comment-14245796 ] 

Cosmin Lehene edited comment on MESOS-898 at 12/14/14 3:19 AM:
---------------------------------------------------------------

[~tstclair] 
I checked out your branch and started playing with it.

I've looked at some cmake projects like LLVM, nanomsg and condor and saw there are different "idioms": e.g. Is one CMakeLists.txt per dir preferred over a src/CMakeLists.txt that groups things (e.g. https://github.com/nanomsg/nanomsg/blob/master/src/CMakeLists.txt)

Did you think about how you wanted this done? 

Again, I was just checking it out as I was looking at CLion and I'm not sure how much time (and when) I can give it, but as you already started the work, perhaps we can start maintaining a rebased branch until it's ready.



was (Author: clehene):
[~tstclair] 
I checked out your branch and started playing with it.

I've looked at some cmake projects like LLVM, nanomsg and condor and saw there are different "idioms": e.g. Is one CMakeLists.txt per dir preferred over a src/CMakeLists.txt that groups things (e.g. https://github.com/nanomsg/nanomsg/blob/master/src/CMakeLists.txt)

Did you think about how you wanted this too look? 

Again, I was just checking it out as I was looking at CLion and I'm not sure how much time (and when) I can give it, but as you already started the work, perhaps we can start maintaining a rebased branch until it's ready.


> Transform and audit mesos build process
> ---------------------------------------
>
>                 Key: MESOS-898
>                 URL: https://issues.apache.org/jira/browse/MESOS-898
>             Project: Mesos
>          Issue Type: Improvement
>          Components: build
>            Reporter: Timothy St. Clair
>              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)