Add ENV.cxx14 and option :cxx14

[tschoonj]

Needed for the new glibmm update, which makes every dependent formula c++14 as well...

[ilovezfs]

We may want to do something like this

diff --git a/Library/Homebrew/shims/super/cc b/Library/Homebrew/shims/super/cc
index 14dc058..e50fab8 100755
--- a/Library/Homebrew/shims/super/cc
+++ b/Library/Homebrew/shims/super/cc
@@ -204,6 +204,8 @@ class Cmd
       val  = chuzzle($1) || enum.next
       path = canonical_path(val)
       args << "-L#{val}" if keep?(path) && @lset.add?(path)
+    when /^-std=c\+\+11/
+      args << arg unless cxx14?
     else
       args << arg
     end

and the converse. But it won't help unless args are being refurbished.

[MikeMcQuaid]

Which versions of Clang support this? I looked and couldn't see it scoped for them. I wonder if there's a way to make this implicit/automatic instead; the CXX11 approach has been a bit messy.

[tschoonj]

Well, in order for this to happen automatically, one would need to analyze the code and look for features from C++11, C++14 etc, which seems undesirable to me.

clang supports C++14 fully since 3.4

[MikeMcQuaid]

Well, in order for this to happen automatically, one would need to analyze the code and look for features from C++11, C++14 etc, which seems undesirable to me.

I guess my question would be: what if this flag was passed unconditionally on supported compilers?

[tschoonj]

I am not entirely sure there is guaranteed ABI compatibility between libraries compiled with c++11 and pre-c++11 standards. I am seeing posts on stackoverflow.com where people strongly recommend that all libraries within a project should be compiled with the same standard to avoid trouble. But this will be troublesome when dealing with third party closed-source libraries.

I wonder why was option :cxx11 ever added to Homebrew? At the very least it suggests that not everybody likes there software to be C++11...

Your suggestion also implies that every package containing C++ code needs to get recompiled and rebottled. This would keep Jenkins busy for a really long time...

@fxcoudert Would you mind chiming in here? I am confident your opinion is more valuable than mine 😄

[ilovezfs]

I guess my question would be: what if this flag was passed unconditionally on supported compilers?

We'd almost certainly need an opt-out in that case since not all formulae are actually able to use ENV.cxx11 for setting c++11 (I'm looking at you boost), and the same will be true for c++14.

[ilovezfs]

And ENV.no_cxx14 is about as clear as mud.

[fxcoudert]

For GCC, there is ABI compatibility between pre-C++11, C++11 and C++14 modes. Any ABI incompatibility — there were some in the past — reported will be treated as a bug and fixed.

Regarding clang, I cannot find any statement that this is true nor untrue. However, nothing in the C++11 or C++14 standard actually requires any ABI change, and I guess they would shoot themselves in the foot if they had done so: people frequently compile libraries with different levels of C++ coding. But we could ask for explicit clarification of their position on the matter.

[ilovezfs]

ABI compatibility will likely be much less an issue than behind the scenes magic that causes build failures.

[fxcoudert]

I guess my question would be: what if this flag was passed unconditionally on supported compilers?

There are some backward-incompatible changes in both C++11 (e.g., auto as a storage class specifier) and C++14 (e.g., constexpr), so passing the flag unconditionally could break programs.

[ilovezfs]

One approach would be to not have a DSL for ENV.cxx14, and do -std=c++14 where needed manually, until we figure out exactly how/if we want to unwind the ENV.cxx11 stuff first.

Are we going to have a ENV.no_cxx11 to aid the transition to new c+11-default-everywhere magic? If not, how are we going to deal with the inevitable compile failures?

[MikeMcQuaid]

I guess my question would be: what if this flag was passed unconditionally on supported compilers?

To clarify here on what I actually meant (apologies for 👶 ⛔️ 💤): let's not ever have a CXX14 option but instead enable it automatically when needed.

[ilovezfs]

That will cause build failures without an opt out.

[tschoonj]

By the way, the need for a C++14 flag is gone for now as an update for glibmm was released yesterday, removing the C++14 specific code.

[MikeMcQuaid]

@ilovezfs I agree. Basically I'm 👍 to ENV.cxx14 and 👎 to option cxx14.

[ilovezfs]

Yeah given #2482 option :cxx14 is kind of pointless.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.