[
https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14600254#comment-14600254
]
Alex Clemmer commented on MESOS-898:
------------------------------------
[~vinodkone]:
{quote}
--> Looks like you are adding windows support too (I'm guessing that's your
main motivation to work on this? Stoked to see this btw!). It's probably better
to work on WIN support in a separate patch.
{quote}
First, yes, I'm attempting to contribute Windows (and Windows container)
support to the Mesos project, and yes, this is the first big step. But, please
don't spread it around to too many people just yet -- to the extent possible, I
am hoping to avoid impacting Mesosphere's ability to effectively "launch" the
feature. :)
To your suggestion that we split Windows support into a different patch: it
seems like you're saying it might be better to first contribute a baseline
CMake-based build system, and then extend that to support Windows later. (That
is, I assume you're not talking about how to package up the changes to the C++
code that we will need in order to support Windows, which I assume we all agree
belong in a different patch.) Is that all right?
I'm actually hoping to make x-plat support out of the box a core goal of this
new build system. My rationale is basically twofold: (1) I am basically certain
that I will end up developing a very different build system if we don't make
x-plat support a priority right out of the gate (right now, I'm testing that
each iteration works on both Linux and Windows, which definitely guides the
design a lot), and (2) I've taken care to clearly mark off the Windows-specific
stuff so that we can pull it out easily later if this Windows stuff doesn't
work out. More particularly, I am suggesting this course of action because I
think it will result in the least aggregate work in expectation.
That all said, I understand the hesitation to put stuff into the codebase if it
isn't used, and I'm totally willing to be convinced that I'm wrong. Let me know
if you see something I don't.
To your other issues, that boost issue that you and [~xujyan] is good to know,
so thanks for pointing it out. And, I was actually hoping that one of you had
good knowledge of CMake idioms. :) If we don't have someone with that expertise
on deck, I agree we need to go find it before merge.
> 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)
