> On Jun 25, 2015, at 11:01 PM, Kapil Arya <ka...@mesosphere.io> wrote: > > 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.
Maybe I'm jumping in the middle without the full context, but why don't you just always build the tests? The way I have done this in other project is to always build the tests with noinst_ automake variables. Them "make check" will just depend on tests that are already built. You can then add a --enable-test-suite option to configure to cause the tests to be installed. This would be pretty useful since you could easily build a mesos-tests package for a CI pipeline. >> 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. Note that requiring gcc 4.8 affects everyone who build Mesos. Requiring more recent autotools mainly affects developers since autotools is not required for building from official source releases. J
