Brief survey from the #dev channel: https://mesos.slack.com/ archives/dev/p1481760285000430
Yosemite 10.10: Fail. Compilation error. (by @hausdorff https://mesos.slack.com/archives/dev/p1481760552000435) El Capitan 10.11: Fail. Compilation error. (by @zhitao https://mesos.slack.com/files/zhitao/F3F7WUCNM/-.diff) Sierra 10.12: Success (by @mpark) On Wed, Dec 14, 2016 at 3:27 PM, Joris Van Remoortere <jo...@mesosphere.io> wrote: > The time has come and we finally have `thread_local` support in the Apple > tool chain: > https://developer.apple.com/library/content/releasenotes/Dev > eloperTools/RN-Xcode/Introduction.html > > In our code base we have a special exception for Apple that defines our > thread local to be `__thread` rather than the c++11 standard > `thread_local`. > https://github.com/apache/mesos/blob/812e5e3d4e4d9e044a1cfe6 > cc7eaab10efb499b6/3rdparty/stout/include/stout/thread_local.hpp > > A consequence of using `__thread` on Apple is that initializers for thread > locals are required to be constant expressions. This is not the case for > the c++11 standard `thread_local`. > > I would like to propose that we remove this exception on the Apple platform > now that the Apple toolchain supports the c++11 standard. > > As I am not a common user of the Apple development experience I would like > to ask for some input from the community as to whether requiring this > toolchain update is acceptable, and if we need a deprecation period or if > we can just make this change now. > > I am leaning towards no deprecation period as I am not aware of production > environments running on systems that define `__APPLE__`. > — > *Joris Van Remoortere* > Mesosphere >
