Re: Dropping support for Apple Clang

[Michael Park]

Thanks Dario!
On Thu, Aug 10, 2017 at 12:12 PM Dario Rexin  wrote:

> Hey MPark,
>
> I just did a clean make check on your cpp14 branch with Apple LLVM version
> 9.0.0 (clang-900.0.22.8). It compiles fine and I got 1 test error on the
> first run, on a second run no tests failed, so I assume that’s just a flaky
> test.
>
> --
>  Dario
>
> > On Aug 10, 2017, at 10:09 AM, Michael Park  wrote:
> >
> >>
> >> Which version of Apple’s clang did you try for C++14? The latest version
> >> available is Apple LLVM version 9.0.0 (clang-900.0.22.8).
> >>
> >
> > I tested on
> >
> >  Apple LLVM version 8.1.0 (clang-802.0.42)
> >  Target: x86_64-apple-darwin16.7.0
> >  Thread model: posix
> >  InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> >
> > Till, do you mind trying it out on 9.0.0?
> > You can just try building https://github.com/mpark/mesos/tree/cpp14
> >
> > MPark
> >
> >> On Jul 29, 2017, at 2:38 AM, Michael Park  wrote:
> >>>
> >>> I'd like to drop support for Apple Clang.
> >>>
> >>> With the C++14 upgrade, we'll be requiring many distros to fetch a
> newer
> >>> compiler. In most cases it only takes a few commands to get a newer
> >>> compiler. This is also true of OS X, where clang-4.0 can be easily
> >>> installed with `brew install llvm`.
> >>>
> >>> The current codebase does not compile with Apple Clang under C++14
> mode.
> >> We
> >>> could choose to investigate whether this is a Mesos bug or an Apple
> Clang
> >>> bug, but after doing a brief investigation myself, I feel like it's not
> >>> worth the effort. There are already cases where we need to install a
> new
> >>> compiler on OS X due to Apple Clang releases based on clang-3.8
> >> (MESOS-5745
> >>> ).
> >>>
> >>> Not that Apple Clang was "officially" supported anyway, but we have had
> >>> minor workarounds (e.g., THREAD_LOCAL) to support it.
> >>>
> >>> Please let me know what you think!
> >>>
> >>> Thanks,
> >>>
> >>> MPark
> >>
> >>
>
>

Re: Dropping support for Apple Clang

[Dario Rexin]

Hey MPark,

I just did a clean make check on your cpp14 branch with Apple LLVM version 
9.0.0 (clang-900.0.22.8). It compiles fine and I got 1 test error on the first 
run, on a second run no tests failed, so I assume that’s just a flaky test.

--
 Dario

> On Aug 10, 2017, at 10:09 AM, Michael Park  wrote:
> 
>> 
>> Which version of Apple’s clang did you try for C++14? The latest version
>> available is Apple LLVM version 9.0.0 (clang-900.0.22.8).
>> 
> 
> I tested on
> 
>  Apple LLVM version 8.1.0 (clang-802.0.42)
>  Target: x86_64-apple-darwin16.7.0
>  Thread model: posix
>  InstalledDir: /Library/Developer/CommandLineTools/usr/bin
> 
> Till, do you mind trying it out on 9.0.0?
> You can just try building https://github.com/mpark/mesos/tree/cpp14
> 
> MPark
> 
>> On Jul 29, 2017, at 2:38 AM, Michael Park  wrote:
>>> 
>>> I'd like to drop support for Apple Clang.
>>> 
>>> With the C++14 upgrade, we'll be requiring many distros to fetch a newer
>>> compiler. In most cases it only takes a few commands to get a newer
>>> compiler. This is also true of OS X, where clang-4.0 can be easily
>>> installed with `brew install llvm`.
>>> 
>>> The current codebase does not compile with Apple Clang under C++14 mode.
>> We
>>> could choose to investigate whether this is a Mesos bug or an Apple Clang
>>> bug, but after doing a brief investigation myself, I feel like it's not
>>> worth the effort. There are already cases where we need to install a new
>>> compiler on OS X due to Apple Clang releases based on clang-3.8
>> (MESOS-5745
>>> ).
>>> 
>>> Not that Apple Clang was "officially" supported anyway, but we have had
>>> minor workarounds (e.g., THREAD_LOCAL) to support it.
>>> 
>>> Please let me know what you think!
>>> 
>>> Thanks,
>>> 
>>> MPark
>> 
>> 

Re: Dropping support for Apple Clang

[Michael Park]

>
> Which version of Apple’s clang did you try for C++14? The latest version
> available is Apple LLVM version 9.0.0 (clang-900.0.22.8).
>

I tested on

  Apple LLVM version 8.1.0 (clang-802.0.42)
  Target: x86_64-apple-darwin16.7.0
  Thread model: posix
  InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Till, do you mind trying it out on 9.0.0?
You can just try building https://github.com/mpark/mesos/tree/cpp14

MPark

> On Jul 29, 2017, at 2:38 AM, Michael Park  wrote:
> >
> > I'd like to drop support for Apple Clang.
> >
> > With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> > compiler. In most cases it only takes a few commands to get a newer
> > compiler. This is also true of OS X, where clang-4.0 can be easily
> > installed with `brew install llvm`.
> >
> > The current codebase does not compile with Apple Clang under C++14 mode.
> We
> > could choose to investigate whether this is a Mesos bug or an Apple Clang
> > bug, but after doing a brief investigation myself, I feel like it's not
> > worth the effort. There are already cases where we need to install a new
> > compiler on OS X due to Apple Clang releases based on clang-3.8
> (MESOS-5745
> > ).
> >
> > Not that Apple Clang was "officially" supported anyway, but we have had
> > minor workarounds (e.g., THREAD_LOCAL) to support it.
> >
> > Please let me know what you think!
> >
> > Thanks,
> >
> > MPark
>
>

RE: Dropping support for Apple Clang

[Andy Schwartzmeyer]

Do it. The fewer “officially” supported compilers the better, it’s easier on 
everyone.

From: Michael Park
Sent: Friday, July 28, 2017 5:38 PM
To: dev
Subject: Dropping support for Apple Clang

I'd like to drop support for Apple Clang.

With the C++14 upgrade, we'll be requiring many distros to fetch a newer
compiler. In most cases it only takes a few commands to get a newer
compiler. This is also true of OS X, where clang-4.0 can be easily
installed with `brew install llvm`.

The current codebase does not compile with Apple Clang under C++14 mode. We
could choose to investigate whether this is a Mesos bug or an Apple Clang
bug, but after doing a brief investigation myself, I feel like it's not
worth the effort. There are already cases where we need to install a new
compiler on OS X due to Apple Clang releases based on clang-3.8 (MESOS-5745
).

Not that Apple Clang was "officially" supported anyway, but we have had
minor workarounds (e.g., THREAD_LOCAL) to support it.

Please let me know what you think!

Thanks,

MPark

Re: Dropping support for Apple Clang

[Till Toenshoff]

Which version of Apple’s clang did you try for C++14? The latest version 
available is Apple LLVM version 9.0.0 (clang-900.0.22.8).

> On Jul 29, 2017, at 2:38 AM, Michael Park  wrote:
> 
> I'd like to drop support for Apple Clang.
> 
> With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> compiler. In most cases it only takes a few commands to get a newer
> compiler. This is also true of OS X, where clang-4.0 can be easily
> installed with `brew install llvm`.
> 
> The current codebase does not compile with Apple Clang under C++14 mode. We
> could choose to investigate whether this is a Mesos bug or an Apple Clang
> bug, but after doing a brief investigation myself, I feel like it's not
> worth the effort. There are already cases where we need to install a new
> compiler on OS X due to Apple Clang releases based on clang-3.8 (MESOS-5745
> ).
> 
> Not that Apple Clang was "officially" supported anyway, but we have had
> minor workarounds (e.g., THREAD_LOCAL) to support it.
> 
> Please let me know what you think!
> 
> Thanks,
> 
> MPark

Re: Dropping support for Apple Clang

[Michael Park]

Unfortunately I basically don't know the answer to any of the questions.
Maybe jpeach can help us a little here.


> Is it just a wrapper bound to a particular clang version?


I actually don't know. It do know that it definitely is not stock, released
version of clang. For example, one of the versions of Apple Clang removed
the implementation of `thread_local` that shipped with stock Clang without
a replacement.


> Why does it exist?


I don't really know. I would guess that they want finer control over what
ships with XCode.


> Also, do you know what the versioning scheme is?
>

I don't know this either... closest thing I know of is
https://gist.github.com/yamaya/2924292.

Removing support sounds fine to me as long as there are clear OS X / macOS
> instructions on the getting started page, and ideally we could tell people
> that their "clang" is too old at configure time?
>

Yep, our getting started page already involves installing homebrew, and
`brew install`ing packages such as wget, git, autoconf, etc, so it's as
simple as adding `llvm` to that list.

On Fri, Jul 28, 2017 at 8:38 PM, Michael Park  wrote:
>
> > I'd like to drop support for Apple Clang.
> >
> > With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> > compiler. In most cases it only takes a few commands to get a newer
> > compiler. This is also true of OS X, where clang-4.0 can be easily
> > installed with `brew install llvm`.
> >
> > The current codebase does not compile with Apple Clang under C++14 mode.
> We
> > could choose to investigate whether this is a Mesos bug or an Apple Clang
> > bug, but after doing a brief investigation myself, I feel like it's not
> > worth the effort. There are already cases where we need to install a new
> > compiler on OS X due to Apple Clang releases based on clang-3.8
> (MESOS-5745
> > ).
> >
> > Not that Apple Clang was "officially" supported anyway, but we have had
> > minor workarounds (e.g., THREAD_LOCAL) to support it.
> >
> > Please let me know what you think!
> >
> > Thanks,
> >
> > MPark
> >
>

Re: Dropping support for Apple Clang

[Benjamin Mahler]

Can you also tell us a little more about "Apple Clang"? Is it just a
wrapper bound to a particular clang version? Why does it exist? Also, do
you know what the versioning scheme is?

$ clang++ --version
Apple LLVM version 8.1.0 (clang-802.0.42)
Target: x86_64-apple-darwin16.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/
XcodeDefault.xctoolchain/usr/bin

Removing support sounds fine to me as long as there are clear OS X / macOS
instructions on the getting started page, and ideally we could tell people
that their "clang" is too old at configure time?

On Fri, Jul 28, 2017 at 8:38 PM, Michael Park  wrote:

> I'd like to drop support for Apple Clang.
>
> With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> compiler. In most cases it only takes a few commands to get a newer
> compiler. This is also true of OS X, where clang-4.0 can be easily
> installed with `brew install llvm`.
>
> The current codebase does not compile with Apple Clang under C++14 mode. We
> could choose to investigate whether this is a Mesos bug or an Apple Clang
> bug, but after doing a brief investigation myself, I feel like it's not
> worth the effort. There are already cases where we need to install a new
> compiler on OS X due to Apple Clang releases based on clang-3.8 (MESOS-5745
> ).
>
> Not that Apple Clang was "officially" supported anyway, but we have had
> minor workarounds (e.g., THREAD_LOCAL) to support it.
>
> Please let me know what you think!
>
> Thanks,
>
> MPark
>

Re: Dropping support for Apple Clang

[Aaron Wood]

I'm all for this! I don't see why this would be an issue, especially with
how easy it is to grab things from brew these days.

On Fri, Jul 28, 2017 at 8:38 PM, Michael Park  wrote:

> I'd like to drop support for Apple Clang.
>
> With the C++14 upgrade, we'll be requiring many distros to fetch a newer
> compiler. In most cases it only takes a few commands to get a newer
> compiler. This is also true of OS X, where clang-4.0 can be easily
> installed with `brew install llvm`.
>
> The current codebase does not compile with Apple Clang under C++14 mode. We
> could choose to investigate whether this is a Mesos bug or an Apple Clang
> bug, but after doing a brief investigation myself, I feel like it's not
> worth the effort. There are already cases where we need to install a new
> compiler on OS X due to Apple Clang releases based on clang-3.8 (MESOS-5745
> ).
>
> Not that Apple Clang was "officially" supported anyway, but we have had
> minor workarounds (e.g., THREAD_LOCAL) to support it.
>
> Please let me know what you think!
>
> Thanks,
>
> MPark
>