[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17149461#comment-17149461 ] Andrei Sekretenko edited comment on MESOS-898 at 7/1/20, 2:02 PM: -- Now we have an installable cmake build that can be used in production. I'm closing this epic as Fixed, finally. Moved the issues needed to achieve full feature-parity with cmake into a new epic https://issues.apache.org/jira/browse/MESOS-10145 and other, non-essential ones into an old epic on cmake improvements: https://issues.apache.org/jira/browse/MESOS-7866 was (Author: asekretenko): Now we have an installable cmake build that can be used in production. I'm closing this epic as Resolved, finally. Moved the issues needed to achieve full feature-parity with cmake into a new epic https://issues.apache.org/jira/browse/MESOS-10145 and other, non-essential ones into an old epic on cmake improvements: https://issues.apache.org/jira/browse/MESOS-7866 > 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: Joseph Wu >Priority: Major > Labels: build, cmake, mesosphere > > 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 (v8.3.4#803005)
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599706#comment-14599706 ] Alex Clemmer edited comment on MESOS-898 at 6/24/15 4:39 PM: - I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for screwing up the posting of this the first time. I don't interact with JIRA much. was (Author: hausdorff): I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. 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
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599706#comment-14599706 ] Alex Clemmer edited comment on MESOS-898 at 6/24/15 4:47 PM: - I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. * This commit spans Mesos, libprocess, and stout (rather than separating them out) mainly to make it easy to consume -- for the real solution, I will happily split them out appropriately. * So far, this prototype commit follows [~haosd...@gmail.com]'s supposition that we want to build the CMake system incrementally and in parallel (though I want to note that stout is a header-only library, and does not need to be built). * I agree that with [~tstclair] that it is probably best that we coalesce libprocess and stout into one sort of systems layer, but given the progress here so far, I'd like to postpone that discussion for another time. I'm willing to rewrite this part of the build system in the event that those changes materialize. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for double posting this. I don't interact with JIRA much. was (Author: hausdorff): I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. * This commit spans Mesos, libprocess, and stout (rather than separating them out) mainly to make it easy to consume -- for the real solution, I will happily split them out appropriately. * So far, this prototype commit follows [~haosd...@gmail.com]'s supposition that we want to build the CMake system incrementally and in parallel (though I want to note that stout is a header-only library, and does not need to be built). Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for double posting this. I don't interact with JIRA much. Introduce CMake as an alternative build system. --- Key: MESOS-898 URL: https://issues.apache.org/jira/browse/MESOS-898 Project: Mesos Issue Type: Epic
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599706#comment-14599706 ] Alex Clemmer edited comment on MESOS-898 at 6/24/15 4:40 PM: - I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for double posting this. I don't interact with JIRA much. was (Author: hausdorff): I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for screwing up the posting of this the first time. I don't interact with JIRA much. 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
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599706#comment-14599706 ] Alex Clemmer edited comment on MESOS-898 at 6/24/15 4:43 PM: - I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. * This commit spans Mesos, libprocess, and stout (rather than separating them out) mainly to make it easy to consume -- for the real solution, I will happily split them out appropriately. * So far, this prototype commit follows [~haosd...@gmail.com]'s supposition that we want to build the CMake system incrementally and in parallel (though I want to note that stout is a header-only library, and does not need to be built). Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for double posting this. I don't interact with JIRA much. was (Author: hausdorff): I'd like to start this conversation with (what I think is) the simplest step forward. I've put together a prototype CMake-based build system that covers libprocess and the third-party libraries, which successfully builds on several flavors of Linux. It is the [last commit of this branch|https://github.com/hausdorff/mesos/commits/test_cmake]. In general, I'm hoping that this will help focus the discussion around concrete things that I need to fix or do less stupidly, to accomplish our goals in this project. Some notes: * I DON'T KNOW CMAKE (OR AUTOCONF), so if it looks like I'm doing something silly, it's because I am! * It's pretty well-commented. I'm hoping it's not too hard to navigate. * It is build to be x-plat at the outset. So, you should be able to take this file and generate makefiles or, like, nmake files. Some things on the roadmap if you all like the progress so far: [x] Third-party dependencies are downloaded, configured, and built when you run `make` (or whatever). [ ] Support for system installations of the third-party dependencies (i.e., we should allow users to use glog if it's already installed on their machine) [x] Tests build and run on multiple flavors of Linux [ ] Benchmarks build and run on multiple flavors of Linux n.b., for issue 2 I have not decided what the right way of communicating the system dependencies to CMake is. In the autoconf solution this comes from `configure`, but CMake will not have a configure step because it needs to run not only on POSIX machines. EDIT: sorry, folks, for double posting this. I don't interact with JIRA much. 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
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=14599866#comment-14599866 ] Alex Clemmer edited comment on MESOS-898 at 6/24/15 6:13 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. This slight delay is mainly because I am 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)
[jira] [Comment Edited] (MESOS-898) Introduce CMake as an alternative build system.
[ https://issues.apache.org/jira/browse/MESOS-898?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=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)
