mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Clemmer <clemmer.alexan...@gmail.com>
Subject Re: Review Request 53550: Rename symbols in log.proto to avoid naming collision in win32 API.
Date Mon, 07 Nov 2016 18:50:50 GMT

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



Worth noting is that the symbol `IGNORE_RESPONSE` is somewhat inconsistent with the naming
convention of the other symbols here, _i.e._, we'd probably expect `ACCEPT` to be changed
similarly to `ACCEPT_RESPONSE` instead. I felt that the benefit of changing all the symbols
to be consistent was not high enough to change them all, though I'm open to other suggestions.

- Alex Clemmer


On Nov. 7, 2016, 6:49 p.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/53550/
> -----------------------------------------------------------
> 
> (Updated Nov. 7, 2016, 6:49 p.m.)
> 
> 
> Review request for mesos, Daniel Pravat and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> The standard win32 headers define a macro, `IGNORE`, which presently
> collides with two uses of the same symbol in log.proto. This causes a
> compile error on Windows.
> 
> In this commit, we rename the symbol in the log.proto files. There are
> two primary reasons for this.
> 
> The first is because the trick we have previously applied to get around
> similar problems (in which we `#undef` the macro, and re-define as a
> global constant) is made somewaht more complex by the fact that the
> log.proto headers are generated by protocol buffers. To implement this
> effectively, we'd have to individually `#undef` at every site we include
> log.pb.h, which is not a huge deal given the number of #include sites,
> but doesn't protect us against future build breaks.
> 
> The second is that the approach of re-naming the symbol in log.proto is
> not very invasive: we need to change a handful of places where the
> system is used, and we never have to think of the issue again. And,
> because it is an internal API, we don't require a major version bump to
> implement the change.
> 
> 
> Diffs
> -----
> 
>   src/log/consensus.cpp 94ddf245c07ccd38d4fe828bc47c98ecf540243f 
>   src/log/coordinator.cpp 72ef0366633b4e4137fd303fa49f9efb166c80c9 
>   src/log/replica.cpp d596e617d4b4eab91245e0a88a3b9479fc75b813 
>   src/messages/log.proto 6a2c26be2afe411e6927cddebcfd9634b2b1b884 
> 
> Diff: https://reviews.apache.org/r/53550/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>


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