> 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?
> 
> James Peach wrote:
>     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 :)

Sounds good to me


- Cody


-----------------------------------------------------------
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
> 
>

Reply via email to