[
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)
