mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Peach" <jpe...@apache.org>
Subject Re: Review Request 35234: libprocess: consistent handling of --enable options
Date Tue, 09 Jun 2015 16:15:48 GMT


> On June 9, 2015, 12:26 a.m., Till Toenshoff wrote:
> > 3rdparty/libprocess/configure.ac, line 31
> > <https://reviews.apache.org/r/35234/diff/1/?file=980998#file980998line31>
> >
> >     Can we switch to `#` prefixed comments here  instead?

Originally I used #-comments, but since autoconf completely elides the macro definition, this
results in the header comments hanging in the middle of nowhere in the resulting configure
script, which just looks weird. If you really want me to change it I will though :)


- James


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/35234/#review87101
-----------------------------------------------------------


On June 9, 2015, 12:04 a.m., James Peach wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/35234/
> -----------------------------------------------------------
> 
> (Updated June 9, 2015, 12:04 a.m.)
> 
> 
> Review request for mesos, Benjamin Hindman, Cody Maloney, and Timothy St. Clair.
> 
> 
> Bugs: MESOS-2537
>     https://issues.apache.org/jira/browse/MESOS-2537
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Let both --enable-$OPTION and --disable-$OPTION work consistently.
> Add bundled package options consistent with Mesos, so that options
> passed down from Mesos work correctly.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/Makefile.am 519e38c2c22904e75f36b936142a915a8f615b21 
>   3rdparty/libprocess/configure.ac 710490b2a7c71f35434494e87e2d132f78ef370a 
> 
> Diff: https://reviews.apache.org/r/35234/diff/
> 
> 
> Testing
> -------
> 
> Make and make check on CentOS 7 and OS X. There's definitely combinations that have not
been tested!
> 
> Note that this removes some login around using gmock. AFAICT the unbundled gmock doesn't
work in the general case. I have a bunch of crashes where the build would pick up gtest headers
from the system and gmock from libprocess 3rdparty. My conclusion is that the only safe path
is to use the bundled gmock. There's no real path through the build to use decoupled gmock
and gtest, it seems to be assumed that gmock will provide gtest.
> 
> 
> Thanks,
> 
> James Peach
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message