----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/29601/#review66947 -----------------------------------------------------------
src/slave/containerizer/isolator.hpp <https://reviews.apache.org/r/29601/#comment110679> I think this can become pretty confusing, both maintainability and semantically. If somehow someone else modifying isolator.hpp decides to use another struct from state.hpp, technically he/she won't need to move the structs here and it will break the modules. Also it's strange to include slave/containerizer/isolator.hpp just to use TaskState and SlaveState as well. Is there a way to expose slave/state.hpp instead? - Timothy Chen On Jan. 6, 2015, 10:39 p.m., Kapil Arya wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/29601/ > ----------------------------------------------------------- > > (Updated Jan. 6, 2015, 10:39 p.m.) > > > Review request for mesos, Niklas Nielsen, Till Toenshoff, and Timothy Chen. > > > Bugs: MESOS-2096 > https://issues.apache.org/jira/browse/MESOS-2096 > > > Repository: mesos-git > > > Description > ------- > > [4/9] Build Mesos Modules outside Mesos source tree. > > This is to make isolator.hpp independent of any other files in src/. There > is one minor glitch with this approach. Apparently, isolator.hpp requires > RunState and TaskState structs that were previously declared inside > state.hpp. The solution was to move these structs from state.hpp to > isolator.hpp. > > > Diffs > ----- > > src/slave/containerizer/isolator.hpp > e82a14201f734292a46b8816c894fa8c766dae5a > src/slave/state.hpp 592182b21ae2700c627f180db38ca5dc1b3c9e8a > > Diff: https://reviews.apache.org/r/29601/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Kapil Arya > >
