On Fri, Jun 26, 2015 at 1:38 AM, Benjamin Mahler <benjamin.mah...@gmail.com> wrote:
> Taking a step back, it looks like the patches in MESOS-2273 approached the > problem assuming 1.13. Have you re-considered how you might approach it if > you didn't have 1.13? Or is this 1.13 macro the only solution? > Hmm, I went back to take another quick look at the situation and here is my conclusion. The automake recursive targets makes the life somewhat easier (and make the code less hackish) by taking care of recursive invocation of the "tests" target for the subdirs. If we didn't have this new macro, the approach would have been to add a "tests" target by hand to the appropriate Makefile.am files (top-level, src/, 3rdparty/, and 3rdparty/libprocess). This is what we have been doing for stuff like "maven-install" and "bench" targets. So, if we were to go for the upgrade path, we might consider rewriting some of these existing targets as well. > Worth noting that users can already build the tests without running them by > specifying GTEST_FILTER="", so is the upgrade pain worth it? With gcc 4.8, > we had a lot of benefits motivating us :) > I do partially agree with you in that with gcc 4.8 we had huge benefits compared to what we get with automake 1.13. Nevertheless, I would like to quote Cody's comment from the RR in response to Dominic's question that was along the same lines: "Not much code, there is runtime / developer slow down overhead in GTEST_FILTER (not documented, build test groups in clusters, just running the constructors/destructors around the tests takes a bit). I can also break the GTEST_FILTER setup (I can add a destructor to a test which will generate SIGSEGV and break a "make check GTEST_FILTER=''" even though tests compile). This should enable parallelizing building all the tests in mesos rather than doing them in chunks which should make things go quicker when I just want to verify the tests build. Also makes it easier to seperate automated builder failure states without relying on undocumented / non-explicit behavior (compiling core, compiling tests, running tests) Similar sentiments were expressed by Joris as well, if I remember correctly. Having said that, if we decide that the automake upgrade path is too much of a hassle, I would like to take a stab at adding the non-recursive "tests" target. It definitely is less hackish than "make check GTEST_FILTER=" :-). Kapil > On Thu, Jun 25, 2015 at 4:10 PM, Kapil Arya <ka...@mesosphere.io> wrote: > > > Apparently, there is a way to get latest the autotools on CentOS 5 > through > > the same community that provides devtoolset: > > https://www.softwarecollections.org/en/scls/praiskup/autotools/ > > > > If the tools are available, would there be any other objections to move > to > > the newer versions? > > > > On Thu, Jun 25, 2015 at 7:02 PM, Benjamin Mahler < > > benjamin.mah...@gmail.com> > > wrote: > > > > > Well, CentOS 5 users don't have to upgrade gcc, they can use > > devtoolset-2. > > > However, devtoolset-2 doesn't provide the newer automake FWICT. > > > > > > On Thu, Jun 25, 2015 at 3:38 PM, Marco Massenzio <ma...@mesosphere.io> > > > wrote: > > > > > > > On Thu, Jun 25, 2015 at 3:27 PM, Cody Maloney <c...@mesosphere.io> > > > wrote: > > > > > > > > > CentOS 5 and 6 don't come out of the box with a new enough version > of > > > GCC > > > > > to compile Mesos. Already they need to upgrade that to compile > > Mesos. I > > > > > don't see how adding another upgrade when they have to do GCC is > > overly > > > > > onerous / should require lots of compatibility hacks to make > > > unnecessary. > > > > > > > > > > > > > +1 > > > > Different story for production servers; but build/dev machines are > > > supposed > > > > to use modern build/dev tools and environments (unless supporting an > > > older > > > > toolchain is a specific need for the project). > > > > > > > > > > > > > > > > > > On Thu, Jun 25, 2015 at 3:17 PM Kapil Arya <ka...@mesosphere.io> > > > wrote: > > > > > > > > > > > It's not available for CentOS 5/6 or the previous debian stable. > I > > > > guess > > > > > > since we still want to keep supporting the older distros, one > > > > possibility > > > > > > is to create a patch for configure.ac which is applied during > > > > > ./bootstrap > > > > > > after detecting the automake version. Is this an acceptable > > solution? > > > > > > > > > > > > If this works, then we can decide on whether we want to patch it > > for > > > > > older > > > > > > (< 1.13) or newer (>= 1.13) automake version. Is there a > preference > > > > > there? > > > > > > > > > > > > Kapil > > > > > > > > > > > > On Thu, Jun 25, 2015 at 2:30 PM, Jake Farrell < > jfarr...@apache.org > > > > > > > > wrote: > > > > > > > > > > > > > we encountered a lot of issues in thrift between all the > > backwards > > > > > > > incompatible changes automake had in 1.12 to 1.14 and trying to > > > > support > > > > > > all > > > > > > > the default versions across different distros. due to this we > are > > > > > > switching > > > > > > > to cmake as well > > > > > > > > > > > > > > -Jake > > > > > > > > > > > > > > > > > > > > > On Thu, Jun 25, 2015 at 1:46 PM, Benjamin Mahler < > > > > > > > benjamin.mah...@gmail.com> > > > > > > > wrote: > > > > > > > > > > > > > > > What about CentOS 5 and 6? > > > > > > > > https://en.wikipedia.org/wiki/CentOS#End-of-support_schedule > > > > > > > > > > > > > > > > Also, how does this interact with the effort to use CMake? > > > > > > > > https://issues.apache.org/jira/browse/MESOS-898 > > > > > > > > > > > > > > > > On Thu, Jun 25, 2015 at 10:40 AM, Kapil Arya < > > > ka...@mesosphere.io> > > > > > > > wrote: > > > > > > > > > > > > > > > > > Hi All, > > > > > > > > > > > > > > > > > > First off, I am not sure if we record the minimum required > > > > version > > > > > of > > > > > > > > > automake/autoconf somewhere in the documentation. > > > > > > > > > > > > > > > > > > Having said that, I want to propose to move to automake > 1.13 > > in > > > > > order > > > > > > > to > > > > > > > > be > > > > > > > > > able to use the "AM_EXTRA_RECURSIVE_TARGETS" macro which > > allows > > > > us > > > > > to > > > > > > > > add a > > > > > > > > > "test" target to just build the test and not run it. The > > issue > > > is > > > > > > > tracked > > > > > > > > > at https://issues.apache.org/jira/browse/MESOS-2273 and > the > > > > > > > > corresponding > > > > > > > > > RRs have received some ship-its. > > > > > > > > > > > > > > > > > > Best, > > > > > > > > > Kapil > > > > > > > > > > > > > > > > > > ================== > > > > > > > > > Compatibility notes: > > > > > > > > > Automake 1.13 came out in 2013 and here is the > compatibility > > > > status > > > > > > for > > > > > > > > > leading distros: > > > > > > > > > * Debian: Since 8.0 [1]. > > > > > > > > > * Ubuntu: Since 13.10 [2]. > > > > > > > > > * Fedora: Since Fedora 20 [3]. > > > > > > > > > * Centos: Since 7.0 [4]. > > > > > > > > > > > > > > > > > > 1. https://packages.debian.org/jessie/automake > > > > > > > > > 2. https://launchpad.net/ubuntu/trusty/+package/automake > > > > > > > > > 3. https://apps.fedoraproject.org/packages/automake > > > > > > > > > 4. http://mirror.centos.org/centos/7/os/x86_64/Packages/ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >
