Re: [E] Re: The state of cmake
Will do! There is one big issue I hit on OS X which I’ve spoken with Andrew about. Whenever I run make with any kind of parallelism I run into this https://issues.apache.org/jira/browse/MESOS-7559 Since this applies to OS X it’s not really a blocker for us but it seemed a bit strange... On 6/22/17, 11:56 AM, "Jeff Coffler" <jeff.coff...@microsoft.com.INVALID> wrote: >Thanks Aaron. Do keep in touch if you have any issues or find any >problems. > >I use the cmake system routinely (daily) to build both Linux and Windows, >and it works for us. I know others are using cmake too, but that said, it >is very new. If you have any problems or issues, we'd love to hear about >it! > >/Jeff > >-Original Message- >From: Wood, Aaron [mailto:aaron.w...@verizon.com] >Sent: Thursday, June 22, 2017 8:28 AM >To: dev@mesos.apache.org >Subject: Re: [E] Re: The state of cmake > >Thanks for the info everyone. I think this might be good enough for us to >move forward with since we don¹t need python/java bindings and we're >doing our own packaging/release anyway. >It might be nice to compile an exhaustive list of the differences between >the two since there might be small differences that most people might not >be aware of. For example, we¹d like to apply some hardening that¹s >already built into the auto tools side. We can apply it manually via >cmake flags for now so it¹s not a huge deal that it¹s not yet built into >the cmake system. > >Also, I¹ll help improve upon the cmake system as much as I can going >forward. We¹ll switch over to it sometime this month and contribute >patches if anything comes up :) > >Thanks, >Aaron > >On 6/21/17, 7:55 PM, "Joseph Wu" <jos...@mesosphere.io> wrote: > >>Here's the earlier email which has the feature comparison: >> >>https://urldefense.proofpoint.com/v2/url?u=https-3A__na01.safelinks.prote >>ction.outlook.com_-3Furl-3Dhttps-253A-252F-252Furldef=DwIFAw=udBTRvFv >>XC5Dhqg7UHpJlPps3mZ3LRxpb6__0PomBTQ=Of4_2lOwuO41tqndIfzTuDYukljy48QGHOj >>PpLG5Ikg=Kbf1mNnwqoVDP_nRFnEMJkWFlQ7dkugg_f38iO3TBV4=xINJ-lZPWHDb5egk >>X_quFAQdG66T1NBevls9LOUIVOE= >>ense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__lists.apache.org_thre >>ta=02%7C01%7CJeff.Coffler%40microsoft.com%7C0866d0b62c4c41ee661808d4b98 >>46cd8%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636337425797116263 >>data=W9EK1VdNuHjc28EpiD%2F9pDMMudA4DhGEgYFVzq%2B5NKk%3D=0 >>ad.html_527a29b45c52a042c122c96754804983b1447b7409ffec3d635b7143-40-253 >>Cde >>v.mesos.apache.org-253E=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__ >>0Po >>mBTQ=Of4_2lOwuO41tqndIfzTuDYukljy48QGHOjPpLG5Ikg=tIOFEs3nvAbyrLpDdQ >>9tT >>Kuxp5VhX6z8CQCst_-pDLE=0H1X-xMm47jKQK8V25a60ZtbR3vHm83i7BK3sqnij2c= >> >>The list is still accurate, except that precompiled headers are no >>longer "upcoming". >> >>On Wed, Jun 21, 2017 at 4:42 PM, Jeff Coffler < >>jeff.coff...@microsoft.com.invalid> wrote: >> >>> Hi Aaron, >>> >>> I'd like to expand on what Andy said: >>> >>> If you want cross-platform development, then cmake is the only way to >>>go. >>> For example, if you want to build on Windows, you MUST use cmake. We >>>anticipate, over time, that cmake will replace the autotools build (we >>>do not want to maintain two build systems). The cmake system is also >>>much more expandable (for example, while this hasn't been done on >>>Linux, Windows had dramatic speed improvements through the use of >>>precompiled headers - if someone was inclined to spend the time on >>>Linux, I imagine similar speed improvements are possible). Note, by >>>the way, that ReviewBot runs on Windows; if you break the Windows >>>build, you need to fix it prior to committing changes. >>> >>> I would say: If you don't care about Java or Python bindings, and >>>you're doing development (i.e. you don't need an installable >>>package), then cmake is a fine way to go. But if you need something >>>that only autotools does today, then you don't really have a choice. >>>Regardless, when you commit a change, you need to be sure that both >>>build systems work properly. >>> >>> Note that cmake is compatible with ccache. Also, FWIW, cmake also >>>gives you very nice "percentage done" notifications on Linux (i.e. >>>85% done, or whatever), which is super nice to know how far along you >>>are. That's a very cool feature that I just love. >>> >>> I agree that we sorely need a concise list of features that are >>>missing. >>> We need
Re: [E] Re: The state of cmake
Thanks for the info everyone. I think this might be good enough for us to move forward with since we don¹t need python/java bindings and we're doing our own packaging/release anyway. It might be nice to compile an exhaustive list of the differences between the two since there might be small differences that most people might not be aware of. For example, we¹d like to apply some hardening that¹s already built into the auto tools side. We can apply it manually via cmake flags for now so it¹s not a huge deal that it¹s not yet built into the cmake system. Also, I¹ll help improve upon the cmake system as much as I can going forward. We¹ll switch over to it sometime this month and contribute patches if anything comes up :) Thanks, Aaron On 6/21/17, 7:55 PM, "Joseph Wu" <jos...@mesosphere.io> wrote: >Here's the earlier email which has the feature comparison: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.apache.org_thre >ad.html_527a29b45c52a042c122c96754804983b1447b7409ffec3d635b7143-40-253Cde >v.mesos.apache.org-253E=DwIBaQ=udBTRvFvXC5Dhqg7UHpJlPps3mZ3LRxpb6__0Po >mBTQ=Of4_2lOwuO41tqndIfzTuDYukljy48QGHOjPpLG5Ikg=tIOFEs3nvAbyrLpDdQ9tT >Kuxp5VhX6z8CQCst_-pDLE=0H1X-xMm47jKQK8V25a60ZtbR3vHm83i7BK3sqnij2c= > >The list is still accurate, except that precompiled headers are no longer >"upcoming". > >On Wed, Jun 21, 2017 at 4:42 PM, Jeff Coffler < >jeff.coff...@microsoft.com.invalid> wrote: > >> Hi Aaron, >> >> I'd like to expand on what Andy said: >> >> If you want cross-platform development, then cmake is the only way to >>go. >> For example, if you want to build on Windows, you MUST use cmake. We >> anticipate, over time, that cmake will replace the autotools build (we >>do >> not want to maintain two build systems). The cmake system is also much >>more >> expandable (for example, while this hasn't been done on Linux, Windows >>had >> dramatic speed improvements through the use of precompiled headers - if >> someone was inclined to spend the time on Linux, I imagine similar speed >> improvements are possible). Note, by the way, that ReviewBot runs on >> Windows; if you break the Windows build, you need to fix it prior to >> committing changes. >> >> I would say: If you don't care about Java or Python bindings, and you're >> doing development (i.e. you don't need an installable package), then >>cmake >> is a fine way to go. But if you need something that only autotools does >> today, then you don't really have a choice. Regardless, when you commit >>a >> change, you need to be sure that both build systems work properly. >> >> Note that cmake is compatible with ccache. Also, FWIW, cmake also gives >> you very nice "percentage done" notifications on Linux (i.e. 85% done, >>or >> whatever), which is super nice to know how far along you are. That's a >>very >> cool feature that I just love. >> >> I agree that we sorely need a concise list of features that are missing. >> We need to understand what's missing, and judge how often missing >>features >> are used, in order to "fully bake" the cmake build system in Mesos. >> >> /Jeff >> >> -Original Message- >> From: Andy Schwartzmeyer [mailto:andsc...@microsoft.com.INVALID] >> Sent: Wednesday, June 21, 2017 4:12 PM >> To: dev@mesos.apache.org >> Subject: RE: The state of cmake >> >> Hi Aaron, >> >> The biggest difference right now is that the Java and Python bindings >>are >> not built whatsoever with the CMake build system. We also do not have an >> install target, so the CMake output is kind of stuck in "developer mode" >> and it won't generate an installable package. >> >> I probably would not yet recommend the CMake build system for production >> use. >> >> As far as what features are missing, I'm not aware of a concise list, >>but >> agree this is needed. Perhaps Joseph knows of one. If one does not >>exist at >> all, perhaps it's time we audit the issues and do a comparison of the >>two >> build systems as they stand now to generate this list. >> >> Cheers, >> >> Andy >> >> From: Wood, Aaron<mailto:aaron.w...@verizon.com> >> Sent: Wednesday, June 21, 2017 4:00 PM >> To: dev<mailto:dev@mesos.apache.org> >> Subject: The state of cmake >> >> Hi all, >> >> I'm curious as to what the current state of came is on Linux. I noticed >> that some features that are present in the autotools build are not yet >>in >> cmake. Also, the output from a successful cmake build looks a bit >>different >> as far as the number of libraries that are produced and the number of >> symlinks created. >> >> While the output of a cmake build does seem to work fine on Linux, is >> there anything to be aware of that would cause issues for a production >> release? Is there a list of features somewhere that are in autotools >>but >> not yet in cmake? Does anyone think it is an exceptionally bad idea to >>use >> the current cmake system to produce binaries for production use? >> >> Thanks! >> -Aaron >> >>
The state of cmake
Hi all, I'm curious as to what the current state of came is on Linux. I noticed that some features that are present in the autotools build are not yet in cmake. Also, the output from a successful cmake build looks a bit different as far as the number of libraries that are produced and the number of symlinks created. While the output of a cmake build does seem to work fine on Linux, is there anything to be aware of that would cause issues for a production release? Is there a list of features somewhere that are in autotools but not yet in cmake? Does anyone think it is an exceptionally bad idea to use the current cmake system to produce binaries for production use? Thanks! -Aaron
Re: [E] Re: Require GCC >= 4.9
Okay, I can add some logic to use the appropriate flag depending on the compiler version. At least that way there is some sort of stack protection for either case. Thanks, Aaron On 10/11/16, 11:14 AM, "Joris Van Remoortere" <jo...@mesosphere.io> wrote: >If the only win is the introduction of that flag I would tend to agree >with >Evers. > >The last time we bumped the compiler versions Cody did an analysis of all >the major platforms and the ability to attain one of the required >compilers >easily. > >If we want to pursue bumping the minor versions for larger reasons (for >example when we wanted c++11) we'll need to propose the change and provide >some deprecation period regardless. > >― >*Joris Van Remoortere* >Mesosphere > >On Tue, Oct 11, 2016 at 4:53 AM, Evers Benno <ben...@yandex-team.ru> >wrote: > >> To be honest, I still think it's a pretty big pain to require a custom >> compiler for mesos. From a packagers perspective, I would have to decide >> if I should upload the PPA package to our repositories, backport gcc-4.9 >> myself, or just revert this patch in our build. >> >> It would also raise the barrier of entry for newcomers quite a bit, >> right now the instructions at https://mesos.apache.org/gettingstarted/ >> are basically just "install this list of packages". >> >> Given that you probably have to add a check to configure.ac anyways to >> warn people if their compiler doesn't support this option, would it be >> an option to use -fstack-protector-strong on compilers that support it >> and -fstack-protector otherwise? >> >> Best regards, >> Benno >> >> On 10.10.2016 20:39, Wood, Aaron wrote: >> > Hi, >> > >> > -Wall and -Werror have been set on Mesos for quite some time now. It¹s >> > only in libprocess and stout that they were never set. >> > Good point about trusty not including gcc 4.9. Do you think it would >>be >> > acceptable to instruct people to take it from the toolchain PPA? >> > https://wiki.ubuntu.com/ToolChain#PPA_packages >> > >> > Thanks, >> > Aaron >> > >> > On 10/10/16, 2:18 PM, "Evers Benno" <ben...@yandex-team.ru> wrote: >> > >> >> Hi, >> >> I think this would break the build on ubuntu trusty, the latest >>natively >> >> available version there is 4.8.2 >> >> >> >> Also, glancing at your review, I feel like `-Wall -Werror` is >>somewhat >> >> of an anti-pattern, it just seems to guarantee that the build will >>break >> >> whenever the compiler writers decide to add a new warning in the >>future, >> >> or when someone tries building with another compiler. >> >> >> >> Best regards, >> >> Benno >> >> >> >> On 10.10.2016 20:07, Wood, Aaron wrote: >> >>> Hi everyone, >> >>> >> >>> I am proposing that Mesos requires GCC >= 4.9 going forward instead >>of >> >>>> = 4.8.1. This is mainly to support -fstackprotector-strong. >> >>> See the related RR here https://reviews.apache.org/r/52645/ >> >>> >> >>> How does everyone feel about this? >> >>> >> >>> Thanks, >> >>> Aaron >> >>> >> > >>
Re: [E] Re: Require GCC >= 4.9
Hi, -Wall and -Werror have been set on Mesos for quite some time now. It¹s only in libprocess and stout that they were never set. Good point about trusty not including gcc 4.9. Do you think it would be acceptable to instruct people to take it from the toolchain PPA? https://wiki.ubuntu.com/ToolChain#PPA_packages Thanks, Aaron On 10/10/16, 2:18 PM, "Evers Benno" <ben...@yandex-team.ru> wrote: >Hi, >I think this would break the build on ubuntu trusty, the latest natively >available version there is 4.8.2 > >Also, glancing at your review, I feel like `-Wall -Werror` is somewhat >of an anti-pattern, it just seems to guarantee that the build will break >whenever the compiler writers decide to add a new warning in the future, >or when someone tries building with another compiler. > >Best regards, >Benno > >On 10.10.2016 20:07, Wood, Aaron wrote: >> Hi everyone, >> >> I am proposing that Mesos requires GCC >= 4.9 going forward instead of >>>= 4.8.1. This is mainly to support -fstackprotector-strong. >> See the related RR here https://reviews.apache.org/r/52645/ >> >> How does everyone feel about this? >> >> Thanks, >> Aaron >>
Require GCC >= 4.9
Hi everyone, I am proposing that Mesos requires GCC >= 4.9 going forward instead of >= 4.8.1. This is mainly to support -fstack–protector-strong. See the related RR here https://reviews.apache.org/r/52645/ How does everyone feel about this? Thanks, Aaron
